The Confidence To Deploy Before Drinks

When I started in IT back in 2000, I was working on radar systems at Thales, making sure hardware and software connections worked perfectly. Those were projects where failure simply wasn't an option. If something went wrong, it could cost the business millions of euros. That's where I learned that you can't add quality in after the fact. It has to be built in from the start.

Over the years, I've worked in many different environments, from international training and consultancy to digital transformation projects in insurance, finance, and government. Each time, I've seen the same pattern: the faster teams learn, the higher the quality. Feedback early and often is what builds confidence. That's what Quality at Speed is about.

Having the confidence to deploy on Friday (just before work drinks) means your team can release before the weekend, without spending Saturday and Sunday sweating. That confidence means your process is healthy. It means your tests, your automation, your collaboration — they're all working together.

Most teams don't fear technical failure. They fear uncertainty.

The Friday release is a cultural test. It shows whether people trust their tools, their code, and each other. When they do, speed stops being a risk.

That confidence has become more important than ever. The pace of technology keeps accelerating with new frameworks, new expectations, and new ways of working. We're now in the era of AI. Organisations want to move faster, but too often compromise quality at the end of the cycle. That's when things start to crack. They release quickly, but not safely, and they automate without understanding what's behind it.

Quality at Speed is my way of bringing those worlds back together. We focus on speed through quality, not instead of it. When delivery, reliability, and learning move together, you get predictable and sustainable progress. Teams that used to release once a week can now deploy several times a day. They do it calmly, confidently, and without losing control.

This philosophy didn't come from a whiteboard session. It came from practice. Working with companies like rb2, DELA, and Rabobank, I saw the same challenges appear again and again. Manual testing slowed everything down. Incidents happened after release. Teams were unsure what "done" really meant. We'd fix the immediate problem. But I wanted to go further — to help organisations design not just their software but their way of working, so quality and speed became the natural state.

I've been lucky enough to compete at European and world championships for software testing. What I took away from those experiences isn't competition: it's teamwork and collaboration. When you work with great people, you learn faster. That's what I want to give to new QA engineers and developers. A space where craftsmanship still matters, even in an age of AI. Automation is powerful, but it doesn't replace understanding. Craftsmanship is knowing why something works, not just how to run it.

That's also why learning is such a big part of what we do. Everyone on my team spends at least four hours a week studying or training. It doesn't matter whether it's new tools, testing techniques, or leadership skills. When people stop learning, teams stop improving, and when teams stop improving, quality quietly disappears.

Quality at Speed is my way of creating that environment — technical, human, and organisational. It's about helping teams build confidence, deliver faster, and enjoy their craft again. Because in the end, quality is a way of working, from the very first line of code to the final deployment before drinks.