The gate gives you the final word. It rarely gives you influence.
For a long time, I thought of my role as the last line of defence. Testing was the point where quality was protected. Things came to us, we examined them and eventually formed a view about whether they were good enough to proceed. If something wasn't ready, we held the line. There was something reassuring about that responsibility because the boundaries were clear. Delivery built, testing assessed and, somewhere towards the end, somebody had to be prepared to say that the evidence wasn't good enough.
On difficult programmes, particularly when deadlines were under pressure, that willingness mattered. I still think it does. There are moments when a testing leader has to hold an uncomfortable position, even when almost everyone else wants to move. What changed for me wasn't the importance of that responsibility, but the realisation that I had begun to confuse authority at the gate with influence over the outcome.
They aren't the same thing.
The gatekeeper has one very visible form of power: the ability to say no. By the time that power becomes necessary, however, almost everything important may already have happened. The architecture has been chosen, scope agreed, delivery dates communicated and dependencies formed. Teams may have spent months building towards an outcome, and senior stakeholders may already have commitments attached to it.
Then testing arrives with a concern.
Sometimes that concern absolutely should stop the release. But it is worth recognising the position the testing leader is now in. They aren't really shaping the decision anymore. They are contesting a decision that has largely already been shaped, and doing so at the point where changing direction is likely to be most expensive.
I didn't appreciate that distinction enough earlier in my career. I thought that being prepared to hold the gate demonstrated the strength of the testing function, and sometimes it did. But as I worked across larger programmes and spent more time around senior governance, I began to notice that the leaders with the greatest influence weren't necessarily those exercising the strongest control at the end.
Often, they were barely talking about gates at all.
They were involved much earlier, while options were still open. Programme leaders asked what concerned them before plans hardened. Architects, delivery leads and business stakeholders wanted their view while there was still time to change something without turning it into a crisis. Their judgement was influencing the conditions that would eventually arrive at testing rather than simply assessing those conditions once they were fixed.
That interested me because some of these leaders weren't any more technically capable than people who remained downstream. What they had developed was a different relationship with the organisation. They had become useful to people making decisions, not simply authoritative when those decisions reached a formal checkpoint.
I gradually came to see that as the difference between guarding quality and influencing it.
A gatekeeper's value becomes most visible when they resist. A trusted advisor's value often appears much earlier, in decisions that become better because they were involved. That doesn't make the advisor a softer version of the gatekeeper, although I think the phrase trusted advisor can sometimes be interpreted that way.
My experience has been almost the opposite.
The people whose judgement senior stakeholders genuinely value are often the people most capable of telling them something they don't want to hear. The difference is that the challenge arrives as part of helping them make the decision, rather than as an obstacle introduced after they believe the decision has already been made. The quality standard hasn't changed. The timing and posture have.
That took some adjustment for me because the gatekeeper identity is strangely comfortable for a profession built around evidence. There is a defined standard, an assessment against it and eventually a conclusion. It creates clear edges around responsibility and gives the testing leader something solid to stand behind.
Advising is less tidy. You are involved while information is incomplete. You may be asked for a view before testing has produced definitive evidence. There may be several reasonable paths, each carrying different risks, and instead of deciding whether something has passed or failed, you are helping people understand choices that haven't yet been made.
Your judgement becomes more exposed in those conversations.
I think that is one reason the transition can be difficult even for very experienced testing leaders. Technical expertise gives us confidence when the evidence is strong. Advisory leadership asks us to contribute while the evidence is still forming. You have to become comfortable saying, in effect, this is what I think based on what we know today, this is where the uncertainty sits, and this is what I would do next.
I no longer see that as a weakening of assurance. I see it as assurance moving upstream.
Once I started thinking about the role that way, I also became less attached to the idea of the veto. Earlier in my career, saying no could feel like the clearest expression of independence. If testing couldn't recommend release, then surely the responsible position was to stop it.
As I spent more time in senior governance, I came to see that the decision was rarely mine alone to make. Testing owns an assurance position. It does not necessarily own the business decision.
That distinction became increasingly important to me. A testing leader should be able to say that the evidence doesn't support release. They should explain why, describe the exposure and be clear about what would need to change for their position to change. But an accountable executive may still decide to proceed after considering the testing risk alongside operational, commercial, regulatory or customer considerations.
That doesn't automatically mean testing has been ignored or overruled. It may simply mean somebody with broader accountability has made a decision they are entitled to make. My responsibility is to ensure they understand what they're accepting and that my own position is clear enough to survive scrutiny afterwards.
That shift from veto to recommendation changed the way I thought about influence. A veto gives somebody two choices: comply with you or override you. A considered recommendation gives them something much more useful. It gives them a position they can examine, challenge, accept or consciously depart from.
Paradoxically, I found that becoming clearer about where my authority ended often gave my judgement more weight. I wasn't trying to take ownership of the decision. I was helping the person who did own it make a better one.
It changed some of my relationships with delivery teams as well.
When testing is experienced mainly as a gate, there is a natural tendency for the relationship to become adversarial, even when nobody intends it to. Defects become arguments about severity. Readiness discussions become negotiations about whether the evidence is sufficient. A late concern isn't simply a quality issue anymore; it can threaten a date that people have spent months working towards.
The same concern raised earlier can feel entirely different. When options remain open, it is still a problem to solve. When it appears days before release, it can become a threat to everything that has already been committed.
I had sometimes attributed that resistance to quality itself. Over time, I realised that what people were resisting wasn't always the concern I was raising. Sometimes they were resisting the cost of hearing about it so late.
That changed my understanding of what it meant to protect quality. Waiting until the end and holding a firm line can look principled, and sometimes it is. But if I could have influenced the decision three months earlier and prevented the problem from reaching the gate at all, that would have protected quality more effectively.
Some of the strongest assurance work I've seen has been almost invisible for precisely that reason. There was no dramatic intervention at the end because the difficult conversations had already happened. A design was challenged early. An assumption was tested before it hardened into a plan. A dependency received attention while there was still time to do something about it.
Nothing was stopped because something had already been changed.
Of course, you don't simply decide to become a trusted advisor and start appearing in earlier conversations. That access has to be earned, and I think this is another important difference between authority and influence. A gate can be assigned to you through process. An advisory role is given to you by people because experience has taught them that your involvement improves the decision.
That reputation builds slowly. People learn that your concerns are proportionate, that you understand more than your own function and that you can distinguish an uncomfortable risk from an unacceptable one. They see that you won't manufacture confidence to support a date, but neither will you exaggerate uncertainty simply to protect yourself.
They also learn that you don't need to have a view on everything.
I've found that the testing leaders who become influential upstream are rarely those who speak most often. They develop a sense for when their perspective materially improves the decision and when the organisation doesn't need another assurance opinion. Restraint matters because judgement carries more weight when people know it isn't being offered automatically.
None of this means the gate disappears. There are still moments when the evidence isn't good enough, when a control has failed or when delivery pressure is pushing an organisation towards a decision it may later regret. A senior testing leader has to be capable of standing firm in those moments.
But there is a difference between being capable of using the gate and building your identity around guarding it.
If saying no at the end is the only meaningful influence you possess, then most of the opportunities to shape the outcome have already passed.
This shift sits at the heart of why I built the Stakeholder Management Masterclass for Test Leaders around influence, judgement and stakeholder confidence. Technical capability remains the foundation. Without it, there is little reason for anyone to trust the assurance position in the first place. But technical authority and organisational influence aren't interchangeable. One may give you responsibility for the gate. The other causes people to ask for your judgement before they get there.
Looking back, I think I held on to the gatekeeper identity for longer than I needed to because it felt both safe and principled. It gave the role clear edges and gave me a clear sense of what protecting quality looked like. I don't regard that period negatively. It taught me the importance of independence, evidence and being prepared to hold an uncomfortable position when necessary.
What I eventually understood was that those qualities didn't have to keep me at the end of the process. They could travel upstream with me.
Once they did, the role changed. I was no longer waiting for the organisation to bring me something so I could judge it. I was helping shape decisions while they could still be changed, while the cost of changing them was lower and before positions had become difficult to unwind.
The gate still mattered. It just stopped being where I wanted to spend most of my time.
Looking back, that was probably the more important shift. The real influence was never in having the last word. It was in becoming useful early enough that, by the time we reached the gate, my judgement had already been part of the conversation.
