It's been a good number of years since I made the conscious decision to move into a delivery role. I thought it was a good time to reflect on it. My move from QA/Test Engineering into Delivery Management wasn’t a departure from quality - it was an expansion of how I wanted to influence it. For a long time, my focus was clear: protecting customers from poor experiences, ensuring systems behaved as expected, and helping teams ship software they could be proud of. Quality was ta

If you work in Agile, DevOps, or platform teams, heated debates are part of the job. Discussions about reliability versus speed, standardisation versus autonomy, or short-term delivery versus long-term sustainability can quickly become intense - especially when production incidents, delivery pressure, or organisational dependencies are involved. These debates aren’t signs of dysfunction. They are signs that people care deeply about building systems that work. The challenge is

Discovery is often misunderstood. Too short, and it becomes guesswork. Too long, and it turns into analysis overload. In modern software delivery, a good discovery phase doesn’t try to design the solution - it creates the conditions and boundaries for a successful delivery to operate in. I'm going to outline what I believe are the key parts of an effective discovery for a modern-day software delivery programme of work. 1. A Clear Problem Statement Discovery should start with

In the world of IT contracting, expectations are clear and often uncompromising. Contractors are brought in as experts: people who can hit the ground running, deliver against a specific remit, and add value from day one. Against this backdrop, the idea of coaching and mentoring can feel awkward, even risky. Why would an “expert” need mentoring? And does offering or receiving it blur lines around independence, especially in an IR35-sensitive environment? Despite these tensions

Have you ever wondered whether the way you make a living and the hobbies you enjoy could complement each other? I work in software delivery, but my camera is never too far away! If you’re a software delivery manager, your world revolves around alignment, clarity, flow efficiency, and helping teams deliver valuable outcomes predictably. But sometimes, the best insights don't come from frameworks, certifications, or delivery models—they come from unexpected places. For me, one

Have you ever wondered whether the way you make a living and the hobbies you enjoy could complement each other? I work in software delivery, but my camera is never too far away! At first glance, software delivery and photography seem like two completely different worlds—one driven by logic, engineering, and systems; the other by creativity, emotion, and visual storytelling. But look a little closer, and the overlap is evident. In fact, many photographers would make excellent

Over the last 12 months, we have seen significant advances in AI technology across many areas, including AI assistants (ChatGPT, Claude, Gemini), Image Generation (GPT-4, Midjourney), Writing tools (Rytr, Sudowrite), and Marketing (AdCreative, AirOps), among others. It's grabbed the attention of many global leaders. I've worked in the IT industry for just short of 20 years, and like anyone else, I would probably say things are constantly changing. Technology moves fast. Among

Let's take a look at some sound engineering principles. Pairing Vs. Code reviews:  Try to avoid treating code reviews as post-development “barriers”. TDD - Tests should be written both by the Developer and QA (It's also not uncommon for others within the team to be involved), preferably in conjunction with each other, throughout the development of functionality - Testing is never an afterthought! Regular, Incremental Delivery – Start by building the smallest unit of value po

End-to-end (E2E) testing can quickly become an ambiguous term, especially when developing microservices. E2E testing in the context of integration between multiple microservices is a bit of an anti-pattern. There is still considerable demand for creating large numbers of E2E regression tests. In a monolithic world, this is without a doubt extremely important when the entire system's function is a single application as an individual, autonomous unit. We have to accept that one

An organisation that I have worked with recently are going through a significant digital transformation. For the organisation, this is an entirely new way of thinking. As a team, we want to revolutionise their ways of working by using new, fast, and frequently changing digital technologies to solve their problems. I have been looking into creating an overarching Testing Strategy. A lot of this isn't information that's uncommon, but I thought it would be helpful to those start