I understand that many teams might find moving to trunk-based development challenging due to a number of reasons (environmental and cultural factors included).

It can feel like too big a shift from long-lived branches and traditional post-development code reviews. However, it does not need to happen all at once. In fact, it should be treated as an agile project: the key is to adapt gradually, breaking the process into small, manageable steps and refining it over time.

It’s a common trap in software teams: treating architecture, security, and quality as someone else’s job. We push those concerns off to specialists, assuming they’ll catch whatever we missed. The architect will figure out how it all fits together. Security will review it before launch. QA will test it thoroughly.

But when we depend entirely on someone else to validate our work (through CABs, architecture reviews, quality gates, or security assessments) we’re not just asking for feedback. We’re quietly delegating ownership. And when that happens, the quality of our output inevitably suffers.

By now, we should all understand what psychological safety is and what it is not. It’s not about being “nice” or avoiding hard conversations.

As Amy Edmondson and Michaela Kerrissey clarify in their recent Harvard Business Review article, psychological safety means creating an environment where people feel safe to speak up, take risks, and be vulnerable in front of each other.

But here’s the catch: the absence of psychological safety is not always obvious. It doesn’t necessarily show up as yelling or overt hostility. Often, it manifests in subtler, sneakier ways.

“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.