Wired for Change: When Tech Stopped Being “Safe”

For a long time — especially in software engineering — there was an unspoken promise: if you were smart enough, fast enough, or technical enough, the rest would work itself out.

That promise no longer holds.

I had the chance to talk with Amy Yee on her podcast Wired for Change about what’s changed in tech, and what engineering leadership demands now. We covered a lot of ground — identity, AI, leadership, values, career paths — but it all comes back to one thing: we have to let go of what we thought was normal, and understand reality as it is.

When Did Things Change?

For me, it was when the mass layoffs started. Before that, doing a layoff was a sign of failure. Somehow it rapidly became a normal thing to do – at volume and in an inhumane way.

The underlying shift is that org size went from a status symbol to liability. The base assumption used to be a large enough group of developers would generate value. Post-ZIRP, all kinds of debt got more expensive. Organizational debt included.

On a human level, a social contract was broken. You saw people who had worked at an organisation for a decade or more just have their access cut one day. Now I think there’s a split between people who think they can out-work or outmanoeuvre being dispensable, and people who know that a job is just a job and their career – and life – is something outside of that, that they need to pay attention to.

The Identity Problem

I don’t think demand has evaporated, but it has changed. I think most obviously, in hiring, it’s a buyer’s market and that means longer, more arduous processes and less good candidate experience. Within organisations, fewer perks and promotions.

External validation was always a shaky foundation. Picking a CS degree at 18 was often arbitrary, and building an identity on it was never healthy. What matters now is clarity about how you bring value.

The job was never to write code – the job was to solve problems and move metrics. What problems or metrics are you responsible for? Do you know what impact you’re having on them? Can other people – like your manager, their manager – tell the impact you’re having?

The 80/20 Shift

Scaling yourself is about building systems and instilling judgment – how you continue to deliver things of value as more is available to you. It was always the case that at a certain level code was not the limiting factor. But with AI that’s happening earlier in someone’s career.

If it used to be the case that a good developer was say, 80% throughput, and 20% team multiplier, that calculation has now changed. Let’s say in 2026 it’s 60:40 – the result is that figuring out how to be a multiplier is more important than ever.

Engineers often used to put off that shift until staff level, but now they need to adjust their mindset earlier. It’s less about the code or language – more about systems design. Being good at systems design, being able to critique, give feedback, and set standards are even bigger levers than before. These were multiplier skills that used to be 20% for strong ICs – not everyone. Now 20% is the minimum, 40% is expected – a bigger part of the role and greater drivers of impact.

AI as a Multiplier

I think about AI as a multiplier, and that’s part of the dissonance around it. Competent, self-aware people use it to get more done. Less competent people use it to generate noise — it’s easier than ever to produce something superficially polished but lacking depth. That creates work for the people reviewing it, and undermines credibility.

Worth naming: we’re all competent and incompetent depending on the task. I have a workflow that makes me produce better written content. I use it for frontend development because I know enough to get adequate results. But when I tried to use it for a professional development policy — something I have no expertise in — I could tell the output was bad but couldn’t fix it. At least I knew, and didn’t waste anyone else’s time.

What You Can Control

Developers have less control than we had before, but all the more reason to use the power we do have well. Nowhere is that more true than over our own choices and attitude in the face of change.

We need to expect to earn our keep. In the ZIRP era I think a lot of software devs lived in some world where they expected to make a lot of money in a way that was divorced from the realities of the business. Now you need to know what value you drive to the business and stay focused on that.

Embrace the idea that your career is bigger than your current job. A bad job is hard, but it’s survivable. You can come back from it. Start with the things you can control – it’s more than you think.

Listen to the Full Conversation

Amy and I talked for over an hour — self-management, feedback, privacy and values, what leadership looks like without authority or abundance. You can watch the full episode here or listen on [Spotify | Apple podcasts]

If this resonates with you, you might be interested in:

• The Engineering Leader – the book
• DRI Your Career – the courses Jean and I are building to support ICs and managers navigating the post-ZIRP era

This isn’t a doom-and-gloom conversation. It’s a reframing — about judgment, agency, and what it means to lead when the old assumptions no longer hold.