Leadership

Three chapters of test leadership, from building a contractor team to coordinating leads across 70+ testers

Building a direct-to-consumer QA team from nothing, leading a distributed EMEA launch under a date set elsewhere, and running a 45–50 person test organisation through release. Each one larger and less comfortable than the last.

1 2015–2017

Building the team that shipped direct-to-consumer

Contractor team I recruited myself

The platform could only be subscribed to through telco partners. Moving to direct-to-consumer meant a new business model, a full design overhaul and a backend rewrite landing at the same time. I hired and built the QA team for it from nothing, and we started writing our own test automation framework alongside the launch.

The cleanest launch I have been part of — put as judgement, not measurement, because the defect figures from that period are not mine to publish.

2 2020–2023

A continental launch with a team I inherited and had never met

Teams of 10–20 people · 5–6 countries · during COVID

The European entity was dissolved into the merged organisation, and I was handed the testing of a programme directed from the US — with my people scattered across five or six countries, none of whom I knew. Remote, mid-pandemic, under a launch date set elsewhere. The work was to turn strangers into a team fast enough to matter.

The EMEA launch landed on a date set elsewhere, with a team I had never met. It is still the bar I measure myself against.

3 2024–2026

A product stuck in development hell, and the org around it

45–50 people · full hiring and performance authority

We took over testing for a product that had been stuck for a year. I owned the hiring strategy and selection, the objectives, the performance reviews and the career management for the whole organisation — later multi-lead governance across 70+ testers.

In production fifteen months later. Around fifteen people were promoted out of that team while I led it, because performance was made visible and careers were managed rather than left to happen.

What I actually believe about running a team

The team first — but not at the expense of the work: Satisfied people do good work. That is not a soft statement, it is an operating one. Most of the craft is balancing what management needs against what the team needs, and refusing to pretend the tension is not there.
Translate the vision, do not relay it: Management intent often lands on a team as an attack. Part of the job is turning it into something the team can actually act on, transparently, without pretending it came from somewhere else.
Under-promise, over-deliver: Commitments are currency. I would rather set an expectation I can beat than defend an optimistic one for six months.
Risk travels immediately, in both directions: From the team to me, and from me to senior management, without delay and without softening. A risk that arrives late is not a risk any more, it is an incident.
Prioritise on return, not activity: I care that my team is working on things that generate actual value for the business — not that they are busy. Anything that stops working gets dropped; anything that works gets reinforced.

How I operate

Underperformance: I look for the cause before the person. In most cases it turns out to be circumstance — unclear scope, a broken process, missing context — rather than capability.
Conflict: Personal friction is usually a symptom. Underneath it there is normally an undefined role or a process that forces two people into each other’s way.
Decisions: The stake decides. Small and reversible goes to the team; large or irreversible stays with me. The same test I now apply to what an AI system is allowed to do alone.
Psychological safety: Regular one-to-ones, and honest criticism was never punished — including criticism of me. I did not defend myself; I either fixed it, escalated it, or handled it within my authority. Outwardly I defended the team.
Leading people stronger than me: Peer review between them rather than approval from me, a high-level understanding good enough to ask the right questions, steering through questions rather than instructions, and one non-negotiable: validated output.

The people work I actually carried, rather than delegated: resolving internal tension, translating management messages downwards, prioritisation and work planning, strategy and its enforcement, hiring end to end, redundancies, one-to-ones, formal performance reviews, career development and promotion, and mentoring — two people became leads under me.

The part most pages leave out

Both chapters ended in redundancy

At HBO it came roughly a year after the merger. At Manpower the client ended the programmes, with the first wave landing immediately before a release.

What I did with it is the only part that is mine to claim. The team stayed motivated and delivered that launch. I selected the list against hard KPIs rather than sympathy, sat in the conversations myself wherever I was allowed to, and spoke to each person again afterwards. I protected the team for as long as I could and went last — including the contractors, who were not technically mine to protect.

I am still on good terms with people I made redundant. I think that is because I was honest with them throughout, and because even at the worst point it was clear we were in it together rather than on opposite sides of it.

Leading when agents do part of the work

I have not run an engineering organisation where agents carry part of the delivery. These are the four things I would take into one — three of them are what I already do, and one is what I would watch hardest.

Set the outcome, not the steps: Work done with agents is non-deterministic by design — a system that behaves identically every time is just a runbook. So the discipline moves from controlling execution to being strict about outcomes: what done means, what triggers escalation, how often we look. That is the same call I already make about delegation: small and reversible goes to the team, large or irreversible stays with me.
Assume review becomes the bottleneck: Generated output arrives faster than anyone can check it, and it is harder to check than hand-written work because it fails by looking plausible. If verification is not designed in, throughput does not actually improve — the queue just moves somewhere less visible. This is the part I know best, and the first thing I would put in place.
Hire for curiosity and domain depth: The people getting the most out of these tools are the ones who understand the problem domain and ask better questions — not the ones who know this year’s framework. I would rather hire someone who understands the customer and the regulation and can now build, than the other way round.
Do not fund senior hires by cutting the entry level: Juniors working with AI ship more and understand less of what they shipped, so growth has to be deliberate: pairing, review duty, and ownership of small end-to-end pieces. Around fifteen people were promoted out of one team while I led it, and two grew into leads. That does not happen if the base is cut to pay for the top.

The framing of the verification tax and the entry-level pipeline I owe to an AWS talk — A leader’s guide to advanced team structures in an agentic world (AWS Events, June 2026). It also proposes specific operating models and team shapes, and I have left those out on purpose: recommending a structure for a team I have never met would be presumptuous. I would want to understand how a team actually works long before suggesting it change shape.

Why this matters for AI work

The hard part of AI adoption is not the model

Most of what stalls an AI programme is something I have already dealt with under another name: two departments measured on contradictory targets, and people being asked to be honest about their own inefficiency in front of a system that might replace them. Neither is a technology problem, and neither is fixed by a better model.

The work is people, incentives and evidence, in that order. That is the part I want to own.

See the work Get in touch