When it comes to DevOps and Platform Engineering, people seem to swing between extremes. Some argue that developers should delegate everything to “DevOps teams”, while others believe developers should manage infrastructure entirely on their own.

That’s a big misunderstanding of both DevOps and PE (surprising?).

I recently came across an argument that developers should not need to know (or even care) about the runtime of their systems. The idea was that platform teams should abstract it away completely so developers do not have to think about it. This view misunderstands how developers and platform teams should work together.

I have heard countless teams complain that “requirements change all the time!”

Many developers crave stability. Constantly shifting priorities can feel like an endless source of frustration. Many blame stakeholders, product owners, business analysts, believing they should spend more time figuring out what they really want before disrupting the team’s flow.

But requirements change for a reason and teams must understand that. Sometimes it happens because the original objectives were unclear. Other times, it is because new opportunities emerge, and adapting to them creates a competitive advantage.

Are we trying to get things more right or less wrong?

I believe there is a fundamental mindset shift between these two approaches: a) We’re doing X well today. We think we have an idea of how to improve X tomorrow. b) We know we’re doing X somehow wrong today. We can’t wait to discover the data that will help us do X less wrong tomorrow.

The first approach is built on pride. It assumes we are mostly right and only need refinement. It consolidates bias.

“My team is great, they haven’t produced a defect in a long time!”

I’ve heard managers say this with pride, but the truth is that “defects per unit of time” is a terrible metric for evaluating a team’s success.

A team that never produces defects isn’t necessarily high-performing. They might just be playing it safe, forced to slow down because the environment around them wants to see heads roll when they make mistakes.

When coding, my motto is: “Design your code to be easily deleted”.

Virtually every principle, pattern, and practice in clean code, design patterns, and software architecture serves a common goal: drawing a dotted line around our component so future developers can easily cut along it, detach our module, discard it, and replace it with something better suited to the evolving needs of the system.

So, let’s not get too attached to our code. It’s not an asset, it’s a (hopefully temporary) liability. The best code isn’t the code that lasts forever. It’s the code that serves its purpose well and then gracefully makes way for something better.

I understand that the ensemble of practices I call T*D (Trunk-Based Development + Test-Driven Development + and Team-Focused Development), can seem daunting at first.

However, in 2025, any software team that aims to be high-performing should prioritise investing time in understanding and adopting each of these approaches.

When combined, these three practices create a powerful framework that enhances software delivery in several ways. They streamline the development process, improve overall code quality, foster a low-stress work environment, and strengthen communication.