Why Technical Excellence Alone No Longer Gets Engineers Promoted in the AI Era

AI has caused a major shift in the way we work and what gets automated inside technical teams. In my work at Sombra, I’ve seen this shift change not only how teams deliver, but also what gets rewarded in career growth. For a long time, the growth path in tech was pretty linear: you learned new skills, kept getting better technically, became someone who solved hard problems, built your reputation and trust, and then earned your way up the career ladder.

But this cycle is now starting to break. AI is taking over a lot of tasks, speeding up work and lowering costs. This doesn’t mean that technical skills aren’t important anymore, but it does make tasks that require judgment, outcome thinking, and decision-making more important.

This is the shift I experienced firsthand on my journey from engineer to co-founder and CTO at Sombra. Five years into my engineering career, I had become the kind of specialist teams lean on. I was the type of employer who could solve difficult technical problems, take ownership of complex work, and be trusted when projects were on fire. But something was missing, and I felt stuck.

It looked like I had hit my career ceiling and could go no further. My technical skills were peaking, but this next growth stage required something different – business thinking.
I couldn’t move forward with only knowing how to build something, I needed to learn what was worth building in the first place.

That kind of ceiling is becoming more common across the industry.

The market is changing faster than many engineers realize

The World Economic Forum reports that 40% of employers expect to reduce workforce where AI can automate tasks, while Anthropic’s research on software development suggests that as AI takes on more repeatable development work, more engineers may be pushed toward higher-level design and decision-making.

Of course, there is still enormous demand for technical talent. Don’t get me wrong, technical hard skills remain core to the profession, but the broader trend is that there are fewer roles where execution alone is enough to move upward. There is a high demand for people who can frame problems, prioritize under constraints, and connect technical work to business value.

That was the transition I had to make. My biggest upgrade wasn’t just technical, it was contextual.

I didn’t leave engineering behind, I expanded it and reframed the questions around it.

I stopped measuring my career growth in terms of “more code,” “more complexity,” or “harder technical ownership” and shifted to architecture, business impact, and decision quality instead.

Five shifts that changed how I worked

This may sound abstract, so I will break it down into 5 practical shifts that helped me develop a business mindset.

The first shift was learning the business directly instead of receiving it secondhand through tickets.

Many engineers work from downstream signals. We get requirements, but not the conversation that shaped them. We don’t get to see the trade-offs behind our tasks, nor the strategic reasons those tasks exist.

So I started learning the business directly. I began attending more sales and support calls, listening to their conversations attentively and paying more attention to stakeholder discussions. Over time, I stopped seeing my work as a series of isolated deliverables.

I came to a realization: а technically elegant solution that arrives too late, costs too much, or solves the wrong problem is not strategic work. It is just expensive correctness.

The second shift was learning the business language without treating it as something reserved for executives.

I started learning all of those terms many engineers are never explicitly taught: ROI, cost of delay, opportunity cost, risk exposure, margin, and sequencing. This is simply inevitable if you’re aiming for senior or C-level positions.

This affects technical judgment, as many specialists are great at solving problems, but they can’t prioritize and evaluate them according to the business goals.

For me, learning that language changed how I communicated and, more importantly, how I judged solutions. The work itself remained technical, but the logic behind it became broader.

That is an important distinction in the AI era. AI can increasingly help teams execute, but it still cannot own the decision-making. That layer belongs to humans.

Another big mindset shift was defining success before writing code.

Over time, before starting implementation, I asked myself a series of questions:

• What exactly does it change for the user or the business?
• Which metric should move?
• How will anyone know it mattered?

Those questions really helped sort things out before I started coding. They also saved me from a common failure: investing heavily in delivery before aligning on impact.

This is one reason measurement matters so much. DORA’s software delivery research has shown the value of measuring how teams deliver software safely, quickly, and efficiently. But in practice, high-performing technical leaders usually go one layer further: they connect delivery metrics to product outcomes and business outcomes.

In other words, shipping is not the finish line. Surely, we estimate results based on delivery, but it’s often the ability to define success in advance that moves someone into broader leadership.

The fourth shift was testing assumptions before you overbuild.

Strong engineers often overbuild, guided by the common misconception that AI makes building cheaper and that more engineering automatically means better quality.

High-performing technical people are often trained to think in terms of robust solutions, as we all want to build things the proper way. This is a great trait to develop, but it often becomes costly when you commit to a full solution before validating assumptions.
That is why one of my most practical shifts was forcing a pause before building and defining my assumptions. Once the assumption is explicit and clear, the work changes shape.

The goal is no longer to prove how sophisticated the solution can be. The goal is to learn quickly, cheaply, and clearly enough to decide what deserves deeper investment.

One last shift that really helped was writing short decision notes before coding.

This may be the most practical habit of all. And don’t get me wrong, I’m not trying to force another document — just a short and structured note to visualize your thinking: what options exist, what risks matter, what impact is expected, what recommendation makes sense, and where alignment is still needed.

This didn’t just improve communication, it exposed weak reasoning early and helped clarify

assumptions (see previous shift). Furthermore, it created a record of why a decision was made, which becomes especially valuable when you review the outcomes.  This small action can change how decisions are framed, communicated, and owned.

In practice, many promotions happen because a person can reduce ambiguity for others, not because they are the most technically brilliant person in the room.

Why the next level is about better decisions

This is the bigger mistake many people make when they talk about AI and technical careers. They frame the story as if the choice is between technical depth and leadership, or between engineering and management.

Technical skill still matters. In many cases, it matters even more because people need enough depth to judge what AI systems are doing, where they fail, and what should or should not be trusted. But technical excellence on its own is less differentiated when more execution can be accelerated by tools. This is exactly what we witness every day at Sombra: the fastest career growth comes when engineers pair technical depth with business thinking.

This does not mean every strong engineer should become a manager. But it does mean the path upward is changing. The next level is less about proving someone can do the hardest task themselves and more about proving they can help a team and a business make better decisions.

I did not hit a wall because I lacked intelligence or discipline. I hit a wall because the next level demanded a wider field of view. Once that changed, my scope changed too.