Every engineering organisation has its stories.
Nobody is ever entirely sure whether these are:
Over the last few posts, I’ve been writing about AI from a fairly close range — how it changes engineering teams, delivery dynamics, capability development, and the shape of organisations.
In other words, the micro view — what happens inside teams when capability, speed, and decision-making all shift at once.
But the more I’ve thought about it, the harder it’s becoming to ignore the bigger picture, as the same forces are playing out at a much larger scale.
Most discussions about AI focus on capability — what it can do, how fast it's improving, and where it might go next.
My last post focused on the fact that less attention is paid to something more subtle, but arguably more disruptive.
Time.
Not just in the sense of speed, but in how time is experienced across different parts of a system.
Because one of the emerging challenges is that time is no longer behaving consistently.
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.
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.
I am not one to shy away from "colourful" language, and I have been known to utilise the odd four letter word to provide emphasis, punctuation, or even comedic effect.
But if I had to ban one four letter word from business vocabulary entirely, I know exactly what it would be:
Just
Conan! What is best in life?
To crush your project deadlines, see them launched before you, and to hear the satisfaction of their users.
When I wrote about my career history late last year in The seven year itch, I called out a few of the projects that I have worked on, but I have been doing some introspection recently as part of updating this site, and realised that I have worked on some incredible projects that I should take more obvious pride in.
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...
If you spend 5 minutes scrolling through LinkedIn[^1], you will no doubt be greeted with multiple "think pieces" about how AI is making everything faster, enabling all of the hustle and grind aficionados to hustle and grind extra hard while they maximise shareholder value, or something.
It sounds great — enabling the worlds most entrepreneurial entrepreneurs to entrepreneur at never-before-seen speed, making a thousand decisions before they've finished their first coffee — but I am personally coming to realise that it has a very specific personal downside when it comes to quality, focus, and cognitive load, and it looks like I'm not the only one.