“Management wants us to be agile and adaptive, but we also must conform to the project’s planned scope, schedule, and cost.”

The Iron Triangle (scope, time and cost) has been a staple of project management for decades. The idea is simple: we can’t change one part of a project, like adding more features, without affecting either the budget or the timeline.

But agile software development thrives on change. It’s all about learning as we go, collaborating closely with customers, and focusing on delivering working software that actually solves problems. So when organisations try to apply the same fixed scope, fixed time and fixed cost approach to agile work, things often start to unravel. Teams are expected to stay flexible and deliver value but are also held to rigid project constraints, and that’s a tough, often unrealistic ask.

“Deploy on a Friday? Are you mad?”

Advising against deploying on Fridays is a classic hype-generating mantra: dramatic, memorable, and often repeated without much examination.

That’s a common reaction, and it’s completely understandable. But those of us suggesting Friday deployments aren’t doing it to be provocative. We do it because we’ve seen what it looks like when teams feel safe enough to do it.

We’ve lived through the pain of not being able to. And we’ve seen the benefits of moving past that fear.

We recently had a chat at work about the difference between multidisciplinary and cross-functional teams. It’s an important difference.

A multidisciplinary team brings together people from different departments or areas of expertise. They’re in the same meetings, they share updates, and they each represent their function. That setup has value, but it’s not the same as being truly cross-functional.

In a cross-functional team, those same individuals don’t just share space, they share ownership. They collaborate closely, make decisions together, and work toward a common goal with a collective sense of accountability. It’s not about representation; it’s about integration.

Event sourcing is often dismissed as an overkill, but in reality, it mirrors how facts unfold in almost every business domain.

It’s an approach that I’ve learned to love over time.

Event sourcing captures the full history of what actually happened, rather than idolising just the current state. Many systems overlook the importance of preserving past events, focusing only on present data. In doing so, they miss out on a gold mine of valuable information.

“He’s dictatorial! He comes from a military background.”

I hear this often when people discuss certain management styles.

Yes, it’s true that command and control (C2) plays a role in the military. But here’s what’s often missed: many of the most progressive leadership philosophies (decentralised decision-making, intent-based leadership, shared ownership) come from military leaders.

Books like:

• Turn the Ship Around! – L. David Marquet, a submarine commander, handed control to his crew and built leaders at every level.

There’s a common idea floating around (especially in FP-heavy circles and anti-TDDers) that if your language has a strong type system (Hindley–Milner, dependent types, etc.), you don’t need TDD anymore. That once we can encode business rules in types, the compiler “proves” our program is correct.

That’s a misunderstanding that I come across so many times.

Let’s clear this up: type systems, compilers, and TDD are not alternatives. They’re complementary tools. Each addresses a different aspect of correctness and confidence in our code.