Accidentally in Code

The benefit of conference season is talking to a lot of people (the downside: needing antibiotics), and of course many of those conversations came to AI, explicitly or not. But underneath the obvious shift there’s an industry one, which started with the end of ZIRP and AI exacerbated. An industry that used to be quite cushy has become more cut-throat. You could call it “higher expectations”, which is often understood to mean higher output.

When output was expensive, we used the cost of it to sidestep a lot of poorly judged ideas by saying they were too much work – less drama and less work than explaining why the ideas were bad. When output gets cheap, one, we can’t hide behind the cost anymore, and two, you discover that increased output is not a pure positive. The person who would go on some kind of crusade for their pet project had human limitations. Now they have a machine and are DDOSing their colleagues.

Lack of judgement used to mean not producing; now it means 10+ pages. Low impact becomes negative impact. In code, that cost shows up as incidents, which at least get measured. Wasted human time we could measure in tokens spent summarising long documents that nobody wrote and nobody read. But the bigger cost is the undermining of confidence and trust between coworkers. Handing your colleague a document you cannot explain and did not think through is something between negative impact and a no-op. And if it’s a no-op, that’s because people have learned not to bother reading the things you send them – arguably worse.

So the expectation that has actually gone up isn’t output; it’s judgement. The value of a butt in a seat producing something, whether that’s code or a backlog, but lacking higher order judgement, is gone. That is the thrust of all these AI-driven layoffs, even if it’s not said explicitly. The companies that aren’t doing layoffs are still doing more intense performance management; with or without layoffs, expectations are higher.

The problem is that judgement is hard to evaluate and critique – because it’s hard to define, and too often means “agrees with me”. “I know it when I see it” was the evaluation standard of the industry for a long time, and whilst improvements have been made, it’s always been the fallback. It doesn’t just mask bias; it makes “the best so far” the proxy for good, which underestimates what good could be. Performance management is no more a science than hiring is, and like hiring, has always been wildly inconsistent even within a single organisation.

You could say engineers were judged by impact, but output was the driver, and “impact” was a bit of a nonspecific term – especially once that impact had to be apportioned across everyone it takes to get something done in an organisation of any size. Non-specific “more”, “better” or “faster” doesn’t work any better now.

The vaguer the role, the harder it gets. Product, a less defined role closest to engineering, is illustrative. Managing a backlog is work, but it only has value if it causes more to get done, which isn’t something we can empirically prove. The real value is in whether the ideas are well founded in what users actually want. Diana Kimball Berlin shared a graphic of Gamma’s research loop which I like for its clarity on what a good product manager does: you can automate a lot of things, but there is judgement in extracting the insights that will actually improve things for the user. For PMs, judgement was always the driver, and the latency of output made it a lagging indicator. Faster feedback has made it easier to evaluate, and possibly explains why I’m hearing from engineers that they didn’t backfill the PM, but instead just used AI.

Even where the standards are defined, they have to keep being aligned on as they get pushed down, which means telling some uncomfortable truths like “we’re not doing a layoff but we do plan to have fewer people working here, so…” The result is that people’s experience is diverging. Managers report feeling compressed by pressure from all sides. Leaders are frustrated that they know what they need, but are missing the tools to get there. ICs are experiencing the pressure as random and unrelated to actual goals, a product of having less power and little or no insight into what’s driving it.

Now it’s not enough to notice whether someone is producing; you have to assess the judgement behind what they produce. Most metrics don’t help, because they measure output too. Shipping with an incident is absolutely not comparable to shipping without one, but we never did a good job of measuring and valuing the work that ensured the problem didn’t happen. Devex, or AI enablement as we’re mostly calling it now, was initially measured on adoption, and is slowly reorienting to the impact adoption drives. Internal teams rarely have CSAT metrics at all, which is why underperforming HR teams go unnoticed (and now is really a bad time for that). Anything that drives output needs to be balanced with effectiveness – in engineering, with reliability being core.

If you’re a leader, this is a blend of new problems and old problems that just moved up the priority list. “Not great but manageable” has become a bottleneck. Teams used to be able to derive their direction from the roadmap; now they need something bigger (a purpose, a mission) to judge it against.

If you’re an IC and the pressure feels random, this is what’s driving it, and you get to choose what to do in it. I see a lot of “this is a bad idea” from ICs, and maybe it is. But if you’re closer to the work, you should have better ones. That’s what judgement is.