Delivery problems often signal structural problems

2026-09-07T08:30:00.000Z

Delivery problems are often caused by structural problems.

Several years ago I stepped into a Lead Software Engineer role at a company that was struggling with its core product and losing customers as a result.

Delivery was painfully slow, the software buggy, and the team was struggling to support new platforms and features. Whilst this looked like a team problem, the actual underlying issue was architectural.

The main application was a tightly coupled monolith. Hardware access, device protocols, persistence, and business logic were all intertwined. Nothing could be tested in isolation. Small changes in one area affected functionality elsewhere. Supporting new devices or platforms required large changes across the whole system.

Before writing anything new, we paused and re-thought the problem.

We structured the system around clear responsibilities and stable APIs/interfaces. Physical devices were isolated behind clean abstractions and tested independently. Product variants were implemented as specialisations over common behaviour. The business logic was then built on top of these layers, rather than sprinkled within them.

Most importantly, this wasn’t a “throw everything away and start again” rewrite. Much of the core functionality already existed and worked well enough, it was simply entangled. The biggest effort involved reshaping/reorganising the system around the clear boundaries so behaviour could be understood, tested, evolved and maintained independently.

Our approach was grounded in well understood design principles; clear ownership of responsibility, controlled dependencies, and interfaces that allowed components to evolve independently rather than any specific technology choice.

It wasn’t just the code that got better.

Our release reliability improved. Supporting UEFI, Windows, Linux, macOS, and proprietary platforms became an integration exercise rather than a rewrite. We were able to use the same core software across products without branching or duplication. What had previously constrained the business became an an asset that allowed us to win more contracts.

This experience strongly shaped how I think and advise: Problems with delivery are often signs of deeper structural problems, and addressing those early, at the architectural level, is usually the highest value intervention available.