Software is not manufacturing. Fund teams, not projects.

When people trained in traditional project management (e.g. construction) step into the world of software delivery, they often face a difficult shift.

In those industries, scope is fixed, timelines are tightly managed, and costs are estimated with precision. Deviations are treated as problems to be avoided.

Software, however, is a different kind of work. It evolves as you build it. Discovery happens along the way. Trying to apply rigid planning models to a dynamic environment creates tension, particularly when it comes to discussing estimates and budgets.

In virtually every organisation I’ve worked with, teams have been eager to experiment. The desire to learn, improve and try new approaches is almost always there. What’s often missing is the environment that allows it.

Software teams must be able to experiment continuously. This is not a luxury. It is a fundamental requirement for solving complex problems and adapting to change.

But experimentation is only possible when teams have autonomy. And autonomy stems from freedom and trust.

Weekend reflection: it’s surprisingly difficult to grasp how an organisation (especially a large one) truly works.

Every company begins as a small group of people with fluid dynamics. Early on, structure follows culture. Norms are shaped by how people collaborate, make decisions, and navigate ambiguity together. But then something shifts. Power dynamics begin to form, roles become formalised, processes start to solidify. Structure takes hold, and gradually, culture starts to follow it.

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.