2025 didn’t happen to me. I showed up and built it. Spoke across continents. Won Best Tutorial at EuroSTAR 2025. Got a book mention. Became an ambassador. Launched courses. Played where it matte...

2025 didn’t happen to me. I showed up and built it. Spoke across continents. Won Best Tutorial at EuroSTAR 2025. Got a book mention. Became an ambassador. Launched courses. Played where it matte...

Leaving it late

I don't typically set goals, and don't share them. But next year is potentially a big one. For me personally, by the time MoTaCon rolls around, I'll have had my 60th birthday, and I'll celebrate by...

Architectural diagrams are visual maps, or blueprints, that show how a software system is put together. They highlight the key components, how they connect, and how information flows between them. You don’t necessarily need every tiny detail of the system. The value comes from seeing the structure clearly enough to understand the system, ask relevant questions, identify potential risks or gaps, and understand how changes and data might travel through the system. A helpful diagram makes the often invisible visible. It shows where the complexity lives, where bottlenecks might appear, and which parts of the system you’ll want to explore, test, or monitor more closely. A diagram can play an important role in understanding a system's testability. Whether the diagram is a simple sketch on a whiteboard in a meeting to help a discussion or decision, or a formal diagram in a tool, the goal is the same. A shared understanding of the system that supports teams making smarter quality and testing decisions.

Software architecture is the high-level shape, or blueprint, of a software system. Architectural decisions, existing circumstances, or context constraints lead to a set of decisions that define how the parts, or components, fit together, how they communicate, how data is used and flows, and how the system evolves, changes, and stays reliable over time. Architecture, most often viewed via architecture diagrams, gives us the big picture so we can make smart choices about design, testing, performance, security, and where the risks sit. You don’t need to know every detail to benefit from understanding architecture. Even reading and understanding a simple view of the main components, their responsibilities, and the data flows can help you ask better questions, spot gaps earlier, and plan testing that aligns with how the system actually works.

A/B testing is a controlled way to roll out a new software version to a subset of users so you can monitor real-world behaviour and limit its use while you gather valuable information about user interaction. Through this technique, you can learn which version of the software is more successful or more liked by users.Sometimes called an A/B release, it means you ship two versions of your product and route traffic so some people see the old version and some see the new one. Think of it as a staged rollout with built-in measurement, so you can stop or roll back quickly if the new version causes bugs or does unexpected harm. It is a broader experimentation method that compares variants to learn which performs better.A simple example of an A/B release:You want to change the checkout flow on an e-commerce site, but you are worried about payment failures. You release the new checkout to 10 per cent of live traffic while 90 per cent keep the old flow. You monitor payment success rates, error logs, and customer support tickets for that 10 per cent, and if problems arise, you halt the rollout and fix the issue before increasing exposure. This is an A/B release because the goal is a safe rollout and operational control, not a pure hypothesis test on conversion rates.Here are some practical tips when considering using A/B testing. Keep the metrics you watch simple and relevant to safety and user value. Automate rollback triggers for obvious failure modes, and treat the rollout as a learning loop where customer reports and small qualitative notes matter as much as conversion numbers. The two main uses are protecting customers and systems, such as in the e-commerce payment example.  And when you need a clear answer to a product hypothesis of what will work best. E.g a button that says 'buy now' and one that says 'special offer'.

This is the code-and-release side. It includes updates to features, bug fixes, configuration changes, infrastructure tweaks, deployments, and anything that alters how the product behaves. Managing these changes well means making risks visible, validating assumptions, testing early, and ensuring releases move through a predictable, safe path into production. In many places, this is done by tickets and committee discussions, informed by information and risk analysis. The greater the risk in industries like finance, medicine, and aviation, the more likely the process will be highly formal.When done well, it should be seen as a way to bring clarity and shared understanding, so teams can move faster with fewer surprises. If done poorly, it can be overly complicated, cause delays and frustration, and add costs. When we handle change intentionally and well, whether it’s how we work or what we ship, we build trust, reduce risk, and make quality a natural part of our delivery.

This is the people-and-process side. It covers shifts in team structure, new ways of working, changes in organisational priorities, and the introduction of new tools and practices. These changes affect how we think, communicate, and collaborate. Good environmental change management helps teams understand what’s happening, why it matters, and how it will affect their day-to-day work. It reduces friction, builds confidence, and gives everyone space to adapt.

Change Management is the structured way we help changes land safely and sensibly, rather than leaving teams to deal with surprises. It comes in two main flavours, and both matter if we want to build and deliver quality consistently.

A matrix organisation is a company structure where people belong to more than one part of the organisation at the same time. Typically, a functional group (engineering, design, testing, data, etc.) and a product, programme, or project team. Instead of a single hierarchy, the organisation is arranged as a grid or “matrix,” allowing skills to move to where they’re most needed.Matrix organisations usually use matrix management to coordinate this dual structure. It’s designed to help companies stay adaptable when dealing with complex products, multiple regions, or rapid scaling. You’ll find matrix structures in large, multi-disciplinary organisations, or where collaboration across teams and specialisms is essential. Some organisations have used and discarded this method due to slower decision-making, role and priority ambiguity, and even power struggles.Working in a matrix organisation means navigating shared ownership, competing priorities, and sometimes conflicting feedback. But when it works well, it gives people a strong home for their professional development while keeping cross-functional teams empowered to deliver real outcomes. When it doesn't work well... watch out.

Matrix management is a way of organising people so they report to more than one leader at the same time. Instead of having a single, straight-line manager, you might have one manager responsible for your professional skills (like testing or design) and another responsible for the product or project you’re currently working on. It’s a structure built for flexibility. Teams can form, reform, and adapt as priorities shift.Matrix management is commonly used inside matrix organisations, where work cuts across functional boundaries. You’ll see this approach in companies that need to balance specialist expertise with fast-moving delivery. Think of big global tech firms, where an engineer might sit in a central discipline group but spend most of their time embedded in a product team.For testers and quality engineers, matrix management usually means having two voices guiding your work. One focused on how you grow your craft, and one focused on what you deliver with your team. Success comes from clarity, communication, and not being afraid to surface tensions when priorities pull in different directions. The challenge is creating an environment safe enough for that to happen, or else divided or conflicting priorities, communication breakdowns, and cognitive overload, amongst other things, can cause major problems.