This is probably obvious.
Here are the 3 things:
Can they describe the system?
Can they create a strategy?
Can they tell a story?
These aren't the only things on the list, but they often get missed.
Here's why these are important.
Mapping the territory.
If you don't know where you are, you can't decide what to do.
We could take many different perspectives to understand any given service or product. The customers using the system, the team building & maintaining the system, the people selling the system, it's a long list! And what's more, they all have equally compelling reasons why their perspective is "right". The tester's job is to synthesise all of these views to understand the dynamics at play and the trade-offs.
It's the software equivalent of the story of the Blind Men and the Elephant!
Decide which problems to tackle first.
There will probably be a target-rich environment when choosing a problem to solve!
In other words, we need a good strategy and creating one isn't as easy it seems. As Richard Rumelt says in the book Good Strategy/Bad Strategy, figuring out which problem to address and how comes in three parts:
Diagnosis - Answers the question "What is going on here?".
Guiding Policy - Describes a method of dealing with the diagnosed situation without specifying precise details.
Coherent Action - Defines the required steps to execute the guiding policy.
It's not enough to do 1 or 2 of the three. They're all needed to improve the current situation.
Energise the team.
Someone will be unhappy with the choice of strategy, so how do we get them onboard?
We need to tell a compelling story about why this problem is the best one to tackle at this time, in this way. Not everyone will agree, but building consensus will only have a chance if you focus on storytelling.
Dry facts alone do not make a compelling story!