When engineering becomes promotion-driven

A few years ago, I started noticing a pattern that, once you see it, you can’t really unsee it anymore.

People are building things not because the business needed them, not because customers asked for them, but because those things looked good in a promotion packet.

And the worst part is that sometimes these people are actually great engineers. That’s what makes this anti-pattern dangerous.

At first glance, it looks like ambition, ownership, leadership, and technical excellence. But over time, you realize that a lot of these decisions are not aligned with impact, they are aligned with visibility.

Ever joined a team and immediately felt someone was trying to optimize for exposure instead of collaboration?

Or maybe you’ve been that person at some point without realizing it.

Hard to admit, but I know I have.

When growth becomes performance theater

One thing I’ve learned while moving through different teams and companies is that promotions can slowly influence the way people behave. Especially in environments with high rotation, reorganizations, layoffs, constant hiring, and changing priorities.

People stop thinking:

“How do we solve the right problem?”

And start thinking:

“How do I position myself as the person solving the biggest-looking problem?”

That subtle shift changes everything.

Suddenly:

• Rewrites become more attractive than iterations

• New frameworks become more attractive than improving stability

• Complex architecture becomes more valuable than simple delivery

• Visibility becomes more important than sustainability

The business needed a practical solution. But the engineer needed a story. And those are not always the same thing.

The cleverest form of opportunism

One of the most difficult things for me is that this behavior is often confused with intelligence.

Some people become incredibly good at identifying moments of instability inside organizations:

• A new team

• A weak process

• A manager trying to please everyone

• A company growing too fast

• A team lacking ownership

And instead of helping stabilize the situation, they optimize for personal leverage.

They force direction instead of building alignment. They introduce unnecessary change because change creates visibility. They push their own way of working regardless of the team context.

Not because it’s better. Because it creates narrative. And narrative gets rewarded.

The hidden cost of “technically correct.”

What made me think more deeply about this topic were some situations I experienced directly.

I saw someone building an internal blogging platform from scratch when perfectly valid external solutions already existed.

Technically, the implementation wasn’t bad. But after the excitement disappeared, what remained was another internal platform nobody wanted to own or maintain.

The business didn’t gain a strategic advantage from it. The team gained operational burden.

I also saw someone creating a huge abstraction layer for a component system. Again, technically impressive. But the abstraction was never about solving a real developer experience problem. It was an optimization looking for a justification.

Instead of reducing complexity, it introduced more friction, more edge cases, and more technical debt.

And this is the dangerous part:

A lot of these decisions are not wrong from a technical perspective. They are wrong from a timing and tradeoff perspective. That’s a much harder skill to develop.

The real seniority skill

I honestly think one of the biggest skills an engineer can develop is the ability to separate personal ambition from business reality.

Not every problem deserves a platform.

Not every pain point deserves an abstraction.

Not every idea deserves a migration.

And not every technically interesting challenge creates business value.

Good engineering is not only about proving that you can build something.

It’s about understanding:

• When to build

• When to simplify

• When to buy

• When to wait

• And when to leave things alone

Sometimes the best technical decision is the least exciting one.

That maturity is hard because engineering culture often rewards visible complexity more than invisible stability.

The one entering the team

Joining a new team is one of the moments where this becomes most visible.

I’ve always believed that newcomers should first understand:

• Why things exist

• What constraints shaped decisions

• What problems the team is actually trying to solve

Fresh ideas are valuable. But arriving with the mentality of “I’m here to fix everything” usually creates more friction than impact.

Sometimes what looks like bad engineering is simply the result of business constraints you still don’t understand.

Adaptability matters more than ego.

The one welcoming the newcomer

The opposite side matters too.

Teams also need maturity to receive fresh perspectives without becoming defensive.

But over time, I’ve learned to pay attention to early signals.

People that:

• Constantly look for exposure

• Need to own every discussion

• Treat collaboration as competition

• Force everyone to adapt to them

• Optimize for perception instead of outcomes

Usually create long-term organizational damage. Not because they lack talent, but because they prioritize individual acceleration over collective sustainability.

The personal trap nobody talks about

The irony is that promotion-driven development doesn’t even help people long-term.

You can spend years optimizing for:

• Bigger initiatives

• More visibility

• More technical complexity

• More cross-team exposure

And still feel disconnected from meaningful work.

Because deep down, building things only to prove you’re capable creates an empty loop.

You stop asking:

“Did this improve the company?”

And start asking:

“Did this improve my positioning?”

That mindset slowly disconnects you from craftsmanship. From teamwork. From the satisfaction of solving real problems.

I’ve seen engineers chase scale, influence, and visibility so aggressively that they completely lost the ability to enjoy simple execution.

And honestly, sometimes the highest leverage work is boring:

• Removing complexity

• Stabilizing systems

• Improving processes

• Helping teams collaborate better

• Saying no to unnecessary change

Those things rarely become promotion stories. But they create healthy companies.

Conclusion

I think ambition is healthy, growth is healthy, and wanting recognition is human.

But when promotions become the main driver behind engineering decisions, companies slowly lose alignment between technology and business. And engineers slowly lose alignment with themselves.

The goal shouldn’t be proving that we are capable of building complex things. The goal should be building the right things for the right reasons.

And sometimes the hardest engineering decision is leaving your personal interests outside the tradeoff discussion.

To wrap up, I also don’t think this is purely an individual problem. Engineers naturally adapt to what organizations reward. If visibility gets rewarded more than impact, people will optimize for visibility.