If everyone’s accountable, then no one is!

This is a common objection I hear when discussing social programming practices like mob programming or pair programming.

The argument often goes that accountability only works when one person is clearly responsible. If everyone shares responsibility, then it’s as if no one owns the outcome. That is, however, a fundamental misunderstanding of what accountability actually means.

Accountability is not the same as blame. Blame is about finding fault. It’s reactive and usually involves assigning responsibility in a way that focuses on punishment or correction.

We can never skip quality.

I keep seeing engineers advocate for a so-called “start-up mode” where shipping fast means cutting corners and dealing with quality later. This is what Robert Martin described as The Start-Up Trap, a fallacy that mistakes recklessness for speed.

Technical debt is not about skipping discipline. It is not an excuse to be sloppy. Rapid iteration means delivering with a limited understanding, consciously incurring that debt, discovering, learning, and paying that debt down. It does not mean sacrificing the integrity of our code. Technical debt is an agile operating model, not a problem. Neglecting it becomes the problem.

One of the best articles I’ve read in a long time, and it’s refreshing to see that it comes from a C-level executive. It resonates deeply.

Too often, people working in technical fields have to fight against an ingrained tendency to create internal divisions. Whether intentional or not, this segregation distances those who build from those who strategise and reinforces an unhealthy separation.

Perhaps it stems from the fact that not many understand the language engineers speak. As a result, technical teams are frequently perceived as outsiders, mere executors of someone else’s ideas rather than valuable contributors to the business vision.

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.