I would guess that it would be the rare situation in your career when you get to build your team out from scratch. What will likely happen is that you inherit and existing team either by being completely new, or being elevated.

In either case, the team, its success and its failures are now yours.

First thing I think you should do is meet with the team as a whole and explain who you are and how you think about testing. Those opinion, rightly or wrongly, will dictate how the team goes about its work.

Next thing is to meet with each team member. The goal here is to find out what makes them tick. Why are they doing what they are doing? What would they rather be doing? Where do they want to be in 1 year? 2 years? 5 years? What do they think needs to be changed?

Of course, during this little ‘interview’, you might find out that the person just isn’t interested in their job, has lost their passion or is just generally burnt out. Well, that is now your responsibility too. As I view the world, you have two choices.

The first is to help them find the fire again. Maybe they like to code, so get them automating something, or analyzing the developer’s unit tests to help improve their coverage, techniques or speed. Perhaps start having lunch-and-learns with Google videos of test techniques that are innovative to your group. (Just remember to bring the food.)

You could also remove them to the position. But with this option comes a loss of institutional knowledge that you likely don’t want.

One way or another, the ones that remain will be dedicated to where you are going and will be passionate about the journey. When I hire, I’ll take passion over (initial) clue any time. You can teach clue. You can’t teach passion.