About

My Story

I started my career in London in 2010 as a QA Engineer. I worked in QA, product and set strategy as an executive, but regardless of my role, my passion has always been working with teams directly, helping inspire and coach teams to deliver the highest quality software possible.

​

I have been fortunate enough to work with many teams during my career, giving me the opportunity to study the intangible factors that ultimately results in the difference between a high performing team and a struggling team. The culture, processes and communication styles, and the importance of honesty and alignment which all contribute to ultimate success.

When remote work suddenly became mandatory in 2020, I realised that the world and the way that we work was about to abruptly change. After taking a year off after Covid to reflect on these seismic shifts, I decided to focus my energy on helping teams to achieve their best results by creating a culture where quality is championed.

​

The traditional quality approach

​

There is a long held belief in the software industry that there is a direct trade-off between quality and delivery.

The iron triangle of time, cost and scope will ultimately result in the quality that you get out, and that at any time, if you want to reduce any of these factors while keeping the others the same, quality will suffer. 

​

This is a fallacy. Yes, in the very short term you can sacrifice quality to deliver more, faster and at lower cost, however it will very quickly backfire, but not for the reason people think.

For years I believed that the problem was the accumulation of tech debt, poor quality code that the team would need to work through. But the debt is not in the code. The debt is in the team. 

Every time a team is pressured to focus on short-term fixes over long-term goals, the team learns that it is better to suffer pain in the future than endure pain today. Every time an engineer is told there is no time for an improvement, they learn that it is pointless to try and change anything. Every time we are told to avoid a conflict, we learn that we don't trust each other. It is not just our codebases but also our teams which are injured.

​

A new perspective

I wanted to take a different approach. One where we focus not on the day to day tasks of delivering code, but rather on creating a culture where the team is encouraged to put quality first, and then let scope, time and cost take care of themselves. And to my great surprise, rather than being a tradeoff, they were directly correlated: the more we invested in the quality of our team, the better our code, the more we delivered and the faster we delivered it.

​

There are many factors that go into a successful team, but there are 3 primary attributes which all effective teams share: They trust each other, they build good processes for themselves, and they have a continuous improvement mindset, backed up by data.

​

Unfortunately it is extremely rare to meet a team who embody all three of these factors. Not because teams are incapable of it, but rather because we are never encouraged to focus on the right things. Conferences are filled with talks about how the latest framework, or design pattern or language will revolutionise the way we develop our software. But when was the last time you attended a talk on how to debate constructively with your team-lead about which approach we should take?

​

My goal is to change the way that the software engineering industry thinks, so that rather than focusing on creating quality software, we focus on creating quality software teams.

​

How do we do it?

Fundamentally it comes down to a number of things which are extremely simple to describe, but very difficult to build. These are the core beliefs that I instil in teams in order to help them achieve their potential:

​

As a team:

• We need to be fully aligned with the organisation's vision, mission and values

• We need to trust the rest of the organisation and the rest of the organisation needs to trust us

• We need to trust and be honest with each other

• We are entitled to the time to constantly improve our craft
• We need to use data to measure the impact we are having

​

That's the theory, but putting it into practice is anything but straight-forward. Every team has its own unique strengths and weaknesses, their own communication styles and practices and no two teams will respond to any single approach. By leveraging my years of experience, I can get to know every team personally and help support and guide them to achieving their potential in whichever way works best for them. 

​

If you want to help your team deliver more, higher quality software faster, while looking forward to work every day, check out my services page and get in contact.