I see a recurring pattern in many companies. Managers complain that their teams are “immature” and that developers “just execute” instead of thinking critically. But let’s take a closer look and we will often find that these same managers create the very behaviours they criticise.

Large companies love command-and-control structures, and the result is a self-reinforcing feedback loop. Managers treat developers as mere executors. Developers behave as expected and focus only on execution. Then managers complain that developers lack ownership. But we do not build ownership by imposing control.

Imagine a tiny sliver of crystal, vibrating millions of times per second. Each oscillation sends a pulse, tiny bursts of electricity that ripple through a network of pathways, setting everything in motion.

Numbers shift from one place to another, stored briefly, altered, and sent elsewhere. Tiny switches flip open and closed in perfect synchronisation, following a meticulously crafted sequence. Gradually, patterns emerge: shapes, words, entire worlds forming from pure logic.

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.