The pitch is seductive and the metrics are real. AI coding assistants measurably improve throughput. Automated testing catches regressions faster. Intelligent infrastructure management reduces operational toil. I've seen it firsthand — the gains are genuine, and any technology leader who isn't pursuing them is falling behind.

But there is a second-order effect that fewer people are willing to name out loud: we are systematically removing the entry points through which engineers learn their craft.

The apprenticeship problem

Great senior engineers are not born — they are built through years of doing work that is now being automated. Debugging a production incident at 2am teaches you things that no course can. Owning a service end-to-end, writing the tests, watching it fail, fixing it, and watching it fail again — that is how deep competence forms.

When AI handles the routine, the junior and mid-level roles that develop those skills start to look redundant. Teams shrink. The pipeline of experience narrows. In five to seven years, we will feel this acutely, and the irony is that the organisations moving fastest today will feel it first.

We are optimising for output at the cost of the humans who generate it. That is not a technology problem. It is a leadership problem.

What I think responsible AI transformation looks like

I am not arguing for slowing down. The competitive pressure is real and the productivity improvements matter. But I believe technology leaders have a responsibility to be deliberate about how they absorb those gains.

• Reinvest headcount into adjacent capability. If AI saves 20% of engineering time, use that capacity for deeper domain expertise, better design thinking, stronger platform work — not just cutting headcount to reduce costs.
• Preserve learning pathways. Junior engineers still need complex work. That means deliberately protecting space for them to own things, fail safely, and grow — even when the AI could do it faster.
• Be honest with your teams. The worst thing you can do is run an AI transformation programme while pretending it has no implications for roles and careers. Your best engineers will see through it, and they will leave before the restructure happens.

The harder question

I think many technology leaders, myself included, are running programmes designed to demonstrate AI value while privately uncertain about where this ends. The honest version of that uncertainty is worth naming: we may be building the tools that make our own roles unnecessary.

That is a genuinely uncomfortable thing to sit with. But I think it is better to face it clearly — and make deliberate choices about what kind of leader you want to be in this transition — than to optimise for short-term output while hoping the harder questions resolve themselves.

They won't. They rarely do.

Every engineering organisation I have seen in trouble has the same surface presentation: processes that look fine on paper, tools that are theoretically adequate, and a leadership team that cannot understand why things keep slipping. The architecture review is rigorous. The sprint ceremonies happen. The OKRs exist.

The problem is almost always the culture. And culture is not a HR programme — it is the set of things that actually happen when nobody senior is watching.

What engineering culture actually is

Culture is the accumulated set of decisions an organisation makes over time, compressed into intuition. It is why one team escalates problems early and another hides them. Why one squad treats on-call as a shared responsibility and another plays hot potato with the pager. Why engineers on one team feel safe saying "I don't know" and engineers on another learn very quickly not to.

These are not personality differences. They are the product of what leaders rewarded, what they tolerated, and what they punished — often without ever intending to punish it.

The signals that actually matter

• What happens after an incident. Blame, or curiosity? The answer to this question shapes every subsequent decision engineers make about whether to take risks.
• Who gets promoted. The person who shipped heroically, or the person who built the system that didn't need heroes? These are not the same thing.
• How disagreement is handled. Can engineers push back on product decisions with evidence? Can they tell a senior leader they think the approach is wrong? If not, you are running on filtered information.

Culture is what you get when you're not paying attention. Architecture is what you build when you are.

Building it deliberately

You cannot mandate culture, but you can shape it through consistent behaviour over time. What I have found works: being explicit about the values you're optimising for, making them visible in actual decisions (not just in a document), and holding yourself to them especially when it's inconvenient.

The hardest part is not knowing what good culture looks like. Most experienced engineering leaders know. The hardest part is maintaining it under delivery pressure — when the shortcut is right there and the deadline is Tuesday.

Streaming at scale is one of those problems that looks solved from the outside. The video plays. The ad loads. The viewer doesn't notice anything. Behind that invisible experience is a genuinely hard distributed systems problem — and behind that systems problem are the people making decisions in real time.

The thing about live events

Recorded content is forgiving. If something goes wrong, the buffer hides it. The user might not even notice a brief hiccup.

Live is completely different. The State of Origin final. The election night broadcast. The NRL Grand Final. These events spike to millions of concurrent viewers with zero notice tolerance. There is no buffer to hide behind. A failure is visible, immediate, and consequential — commercially and reputationally.

What that does to a team is interesting. You either build genuine resilience — in your systems and in your people — or you discover, publicly, that you haven't.

What I learned about systems

• Observability is not optional at scale. You cannot react to what you cannot see. The best investment we made was not in prevention but in detection — knowing within seconds what was happening and where.
• Cloud-native does not mean infinitely scalable by default. Auto-scaling sounds like a solved problem until you watch the scaling lag behind a demand spike. You have to pre-provision, which costs money, and the decision of how much to pre-provision is always a judgement call.
• Edge matters. Moving decisions closer to the viewer — caching, routing, failover — was one of the highest-leverage things we did for both latency and resilience.

What I learned about teams

The engineers who thrive in live streaming environments share a characteristic I have come to value highly: they are comfortable with irreducible uncertainty. They make the best decision they can with incomplete information, act, observe the outcome, and adjust — without needing the situation to be clean before they move.

That is not a skill you can hire for easily. It is something you develop through operating real systems under real pressure. Which is why I am somewhat wary of how much we automate that experience away before the next generation of engineers gets to have it.

The budget cycle is widely dreaded in engineering organisations. It arrives with spreadsheet templates and questions about headcount justification, and it consumes weeks of leadership attention that could otherwise go toward building things. I understand the resentment.

But I have come to see it differently. The budget is the one moment in the year when the technology organisation gets to make a direct, documented argument for its strategic priorities — and have that argument reviewed at board level.

The argument most technology leaders miss

The natural instinct is to defend: justify the existing headcount, protect the current roadmap, argue for incremental increases based on last year's baseline. This is the wrong frame.

The more powerful approach is offensive: what would it take to genuinely shift the competitive position of this product? What capability is missing that, if we had it, would change the trajectory? What technical debt, if we resolved it, would unlock three times the delivery throughput?

These questions reframe the budget conversation from administration to strategy — and they are the questions that CFOs and CEOs actually find interesting.

Show me an engineering organisation's budget and I'll show you what they actually believe their technology is for.

Practical things that work

• Translate technical investment into business outcomes. "We need to re-platform the streaming infrastructure" is a cost. "Re-platforming the streaming infrastructure will reduce time-to-market for new features by 40% and cut per-stream operational cost by 15%" is a strategy.
• Build the investment case before the cycle starts. The leaders who win budget conversations are the ones who have been telling the story for six months before the templates arrive.
• Know what you will cut. Arriving with a list of what you would deprioritise if you had to demonstrates seriousness and earns credibility for the things you won't cut.