Thew new talent bar for software engineers

Web software engineering is changing rapidly. While this shift is not equally distributed and is often easy to overlook in the day-to-day, it is coming whether you are ready or not.

The reality is that writing software is becoming cheaper and faster at an incredible rate, but the systems we’ve built around that production are lagging. Our expectations of who does what - between the engineer, tech lead, PM, or designer - remain rooted in an older era. Our product development cycles, release processes, customer access protocols, and even interview loops were all battle-tested for a world where building a feature took a month. They are not built for a world where that same feature takes a couple of days.

The Innovator’s Dilemma in engineering

We must embrace this change through the lens of the Innovator’s Dilemma. We see AI startups and frontier labs moving with exceptional speed. If you are an incumbent, you need to disrupt your own delivery model. This is about far more than just giving your team Claude Code; it’s about rethinking the entire system: tools, processes, performance expectations, and roles. Engineers are smart and they don’t stay idle. Currently, we see more code being produced everywhere, but too often that code is channeled into areas most comfortable for software engineers: tech debt, low-priority to-dos, minor refactoring or unambiguous small features. While valuable, that isn’t where the real business impact lies.

A useful mental model of you can expand your software as a company gives you three dimensions:

The first two buckets are today constrained by PM and UX bottleneck. Therefore, most AI-driven acceleration in writing software ends up in the third bucket. The real challenge for leaders is shifting those gains into the first and second ones and it’s very hard to do this without evolving the entire system of product delivery.

The new talent bar

To address this, I am explicitly operationalizing three dimensions of talent within my organization at HubSpot through performance expectations and growth plans. To remain competitive, software engineers need to embrace these three pillars:

1. You need to be a Product Engineer

AI is an extension of your agency in delivering business value. Historically, there has been a “fat-head” distribution of impact, where certain, usually very senior, engineers had outsized influence because they could identify and disambiguate high-value problems.

I think that in the coming year we are going to see massive compression of expected behaviours among software engineering levels. What was once a Staff-level behavior - taking ownership of the “surround system” of PMs and designers - is becoming the baseline for mid-level engineers. What will still be obviously different is the expected level of impact - you would expect significantly more differentiation and value from staff than from mid-level engineer. But if an engineer can ship 50-70% more code today, but the PM and design “surround system” isn’t ready for that velocity, they become the bottleneck.

To bridge this, engineers must become subject matter experts in the products they build. You must understand the customer and the business model. You need to be opinionated, research and develop some bets that you want to explore proactively, be able to ask the right questions and find answers yourself, and even think about and act on things like activation, enablement or support.

Being a Product Engineer is about taking ownership of the surrounding system of the past. You need to become a subject matter expert in products you are developing, understand your customers and how you ultimately make money as a business, and be able to identify, and take ownership of actual business outcomes. Performance will increasingly be measured by business impact rather than output metrics like PR counts.

If you would like to learn more about that, some great posts about this:

2. You need to be fullstack

While specialization will always exist, for example in infrastructure, my bet is that the total number of “siloed” engineers will decline. If your value is tied to your ability to deliver business outcomes, you cannot be limited by the stack; business value rarely stops at the boundary of a frontend or backend change. With AI-assisted coding, there is no longer an excuse to specialize in a single language. You must be an engineer who understands the entire system - from browser behavior to distributed system design. You should still cultivate “T-shaped” depth in one or two areas, but you must feel comfortable navigating the entire stack with AI as your navigator.

3. AI is a key part of the stack

AI used to be the exclusive domain of MLEs. Today, it is being democratized. However, the best products are more than just thin wrappers around an LLM; they are complex systems involving RAG, online/offline evaluations, experimentation pipelines, and context management.

These principles are becoming as fundamental as distributed systems design. Just as a backend expert needs to feel comfortable with the frontend, they must now feel comfortable operating within AI systems. AI is no longer a “plugin”; it is a core component of the modern stack.

It’s not your decision. It’s a market decision.

If you don’t lean in now, you risk waking up one day to find you are no longer competitive. This shift toward high-agency, commercially-minded, fullstack engineers is already the “bread and butter” of startups.

For incumbents, the clock is ticking. You cannot catch up to the speed of a hungry startup just by buying tools. Their advantage comes from the entire system of delivery and the shape of the talent they attract. As an engineer, you must grow into these categories. As a leader, you must operationalize them. The tools are available to everyone — the system is what will set you apart.

Ownership explained for Engineers and Managers

Ability to take ownership is critical for your career and is a major step between junior and senior role. See how to look for high-impact ownership for engineers.

What is Principal Engineer role?

Principal engineer usually means the most experienced individual contributor in the organisation. It's an ultimate step in engineer career ladder, but do you know what to expect at this level?

Embrace the stretch

Take advantage of opportunities, prioritize and do the most impactful work as it is the best way to iterate, learn and grow. Embrace the stretch.

Subscribe for new posts!

I post every 2-3 weeks and always with lessons related to software engineering managers. I won't use your email in any other way!