Skip to main content

Performance Reviews in the Age of AI

As Engineering Managers, we’ve always known that impact beats throughput. The best leaders in our industry already look past the raw volume of PRs or the velocity of a sprint to find the engineer who solved a scaling bottleneck with ten lines of configuration. We’ve always valued the person who understood the business problem well enough to realize we shouldn't build the feature at all.

But in the pre-AI era, throughput still served as a useful, if noisy, proxy for effort. If an engineer was shipping a lot, they were at least engaged.

AI has officially broken that proxy. When the cost of generating software approaches zero, the volume of output is no longer a sign of engagement - it is a commodity. For an engineering leader this means that focusing on impact isn't just a best practice anymore. It is the only way to keep your organization from drowning in its own success.

From “Productive" to "Steward"

The fundamental unit of engineering value has shifted. We are moving from an era of Code Production to an era of Systems Stewardship.

In this new landscape, the true high-performers are the ones who provide the "connective tissue" for the organization. As AI makes it easier to spin up isolated services and features, the risk of fragmentation skyrockets. We must now place a premium on:

  • Cohesion over Coverage: It’s easy to use an LLM to hit 100% test coverage or generate a new API. It’s hard to ensure those tests are meaningful or that the API doesn't create a redundant data silo.

  • The "No" over the "Yes": We need to reward the engineer who uses their deep understanding of the business to prevent "feature bloat." In a world where AI can build anything, the most valuable person is the one who knows what not to build.

  • Architectural Integrity: The "Senior" title should be a reflection of an engineer’s ability to audit AI-generated logic against long-term system health. If they can’t explain the why behind a generated pattern, they aren't leading; they're just typing.

Mentorship: Teaching Judgment, Not Syntax

This shift changes the mandate for how we grow our teams. If your Seniors are still mentoring Juniors on the nuances of a library’s syntax, they are teaching a skill that is being automated in real-time.

Mentorship must now focus on Business Context and Architectural Judgment. 

  •  How does this service impact our COGS (Cost of Goods Sold)?

  • How does this data structure affect our ability to pivot next year?

  • Is this AI-generated solution fixing a local problem and creating a global headache?  

We aren't just building coders anymore; we are building Systems Thinkers.



The New Management Standard

When you sit down for your next round of performance reviews, the "Impact vs Throughput" conversation needs to be the centerpiece, not a footnote. Ask your EMs to justify their ratings based on these pillars:

  1. The Context Test: Did the engineer align their technical choices with the specific business problem we are trying to solve this quarter?

  2. The Complexity Tax: Did their work simplify our ecosystem, or did they just use AI to ship more complexity that we now have to maintain?

  3. The Audit Trail: Did they demonstrate the critical thinking necessary to "interrogate" the AI, or did they act as a passive conduit for generated code?

Good managers have always prioritized impact. But today, the gap between "shipping code" and "delivering value" has become a chasm. If we continue to reward throughput, we will end up with a mountain of software that no human actually understands.

The most valuable engineer in your org is no longer the one who uses AI to do the work of three people. It’s the one who uses AI to ensure the work of those three people actually makes sense together.


Comments

Popular posts from this blog

The "Just-in-Time" Manager and the 1:1 Gemini Gem

  We’ve all been there. The calendar notification pings. You finish your previous meeting (which ran over by three minutes), and as the Zoom window for your next 1:1 pops up, you’re frantically tabbing through Google Docs and Slack. You’re trying to remember: What did we talk about last time? Did that project go okay? Wait, did they mention a vacation or a baby? You’re "prepping" while the meeting is already happening. You’re physically present, but mentally, you’re a detective trying to solve the mystery of your own calendar and trying to switch off the last meeting.  It’s a common trap for managers, especially as their direct reports grow and they now have skip level 1-1s, or skip-skip level 1-1s. Our schedules are a mosaic of context-switching, and unfortunately, the deep, reflective prep our direct reports deserve is often the first thing to get squeezed out as we are dealing with incidents or other emergencies.  From "Zero Prep" to "Instant Context" R...

Are Engineering Managers Obsolete in an AI World?

So far in my career, our value as leaders was measured by how well we manage the machine - optimizing for velocity, smoothing out team dynamics, and ensuring predictable delivery of business goals. Now, the engine of that machine is changing. For the past few months a part of me is feeling some existential dread - with AI advancing so quickly the fundamental engine of the machine is changing. A lot of the discussion has been on 10x or 100x engineers, but what is this going to mean for Engineering Managers? Do we still need the role? If we do, what does an Engineering Manager in the future look like? The future - maybe I mean now…  I think it's too early to declare the death of the manager but I am ready to place a few definitive bets on changes that are coming.  Firstly Engineering Managers who don’t stay on top of AI developments will become obsolete. The 'wait and see' approach has become a 'wait and become obsolete' strategy. Within a performance cycle or two I p...

Prompting AI Adoption for Skeptical Engineers

We’ve all seen the headlines. "AI will replace the junior engineer”.  "The 10x engineer is now a 100x engineer." In leadership meetings almost every conversation comes back to velocity and how we could unlock efficiency with AI.  But when you talk with the team the reality can be different. Your most senior engineers - the ones who built the core of your system - are looking at Copilot or Cursor with a squint. Some see it as a toy; others see it as a threat to the craft; a few see it as a glorified Clippy that hallucinates half-baked solutions into their carefully maintained repos. As Engineering Managers and Directors, we are currently in a delicate spot. We are being asked by the business to "leverage AI," but we are being told by some of our best people that it’s "not quite there yet". How do we advocate for AI without sounding like a marketing brochure? How do we move the skeptics without losing their trust? 1. Validate the Skepticism (Because it...