5 posts tagged with "Judgement"

In recent months (and years) I have written about hitting those predictable institutional thresholds — the natural cycles where a senior technologist begins to look at the horizon and ask what comes next. I’ve joked openly about midlife crises, analyzed the predictable patterns of the seven-year itch, and questioned what it means to be a "veteran" in an industry that routinely worships youth.

Now, with my current role coming to an end on 31 August, I’m looking at a very specific set of numbers.

In my most recent posts, I’ve explored how AI is starting to reshape both the structure of engineering teams and the shape of individual capability.

• Teams shifting from pyramids to more diamond-like structures
• Individuals moving from T-shaped profiles towards multi-pillar depth

There’s a third dimension that sits across both: Time.

In my last post, I explored the idea that we may be moving from a knowledge-based economy towards something that places greater emphasis on judgement, framing, and leverage.

That shift doesn’t just affect individuals. It has implications for how we structure teams, how we develop capability, and how we think about the long-term sustainability of engineering organisations.

Most of the conversation around AI today is anchored in the near term.

Engineers are asking how it changes their workflow. Product teams are experimenting with copilots. Founders are looking for leverage. There’s a steady undercurrent of anxiety about junior roles disappearing, but it tends to be framed as a tactical problem, something to manage, mitigate, or route around.

I’m less focused on that layer.

Not because it isn’t important, but because it feels like we are still looking at the first-order effects of a much larger shift.

Today I saw a LinkedIn post from a COO saying:

Today developers who spend 3 days writing "clean" code that someone else would have shipped in 4 hours with AI are no longer rewarded for their dilligence: they're penalised for their slowness.

What the customer is now measuring:

• How many features did you ship?
• Does it work?
• Does it create value?

The market no longer pays for the craft of writing code; it pays for results.
What if the best thing a senior dev can do in 2026 is teach their team to ship faster, not code cleaner?

Friends, I have opinions...