Software engineering is often described as a technical discipline. We talk about programming languages, frameworks, architecture patterns, cloud platforms, databases, testing strategies, and deployment pipelines. We invest significant time teaching engineers how systems work and how to use the tools required to build them. But another skill is arguably just as important, and significantly harder to teach. Engineering judgment. Engineering judgment is the ability to make good

Technology has never evolved as quickly as it does today. New programming languages, cloud platforms, architectural patterns, security threats, automation tools, and AI capabilities are emerging at a pace that makes it almost impossible for traditional training programmes to keep up. For engineering organizations, this creates a significant challenge. It is no longer enough to hire people with the right skills and expect those skills to remain relevant for years. The organiza

For decades, software engineering has largely been synonymous with writing code. Job descriptions focused on programming languages, algorithms, frameworks, and technical expertise. The best engineers were often measured by the quality, efficiency, and quantity of the code they produced. While these technical foundations remain critically important, the role of the software engineer has evolved dramatically. Modern software is no longer built in isolation by individuals workin

Security is often associated with tools: vulnerability scanners, firewalls, monitoring systems, and automated security gates in delivery pipelines. While these technologies are essential, they cannot secure software on their own. The strongest defence against security threats is not a tool; it is the mindset of the engineers who design, build, and operate the systems. Organizations and teams that consistently deliver secure software understand this well. They invest not only

In the previous blog post , we looked at the importance of measuring quality and stability. These are important to ensure failures are reduced and system design remains optimal for the user experience. In complex software systems, failure is inevitable; what defines high-performing teams is not whether incidents happen, but how quickly, safely, and confidently they recover. Reliability and recovery metrics measure the resilience of your delivery ecosystem and your organisatio

I started writing in my previous blog post about the importance of metrics and how they provide detailed insight into the development life cycle and identify key areas for improvement in software delivery for teams. Before delving into the different metrics themselves, though, it’s important to look at how we actually gather the data in the first place. After all, there is no way we can gain insight into our delivery if we don’t have access to the data that provides it. How

The software world may be looking to always deliver innovation and new features faster. However, delivery speed alone is no longer a meaningful indicator of success. Teams are expected to deliver quickly and safely, sustainably, and predictably. Doing so though is a big challenge for many teams and the key to this improvement is understanding your software well and knowing what is going in in your software delivery process very well. This is where metrics play a critical rol

As the industry continues to rapidly adopt Large Language Models (LLMs) to power chatbots, copilots, search, automation, and decision support, one discipline has emerged as a critical success factor: prompt engineering. While LLMs are incredibly powerful, their outputs are highly sensitive to how they are instructed. The difference between a vague, unreliable response and a precise, trustworthy one often comes down to the quality of the prompt. Soemtihng which is a completely