Suppose your boss were to approach you one day and inform you that they were looking to hire another technical staff member for the team and he wanted you to outline the skills required for the position. The specific requirements and position would be left entirely up to your discretion.
What would you do?
Most developers would immediately specify a development position (we always have more software to write). They would then proceed to gather up all the technologies, processes, knowledge and skills currently in use (including domain knowledge), and list those as the requirements for the new position. Most testers would immediately specify a test position (we never have enough testers to go around). They would gather up all the different testing methodologies and techniques being used, add a heavy dose of domain specific knowledge and list those as required skills.
In the end, the new staff member will likely become a useful contributor to the team, things might even get finished faster, but it is unlikely they will make the project meaningfully better.
Now, imagine instead that you are working on a puzzle. The puzzle has a lot of the pieces already filled in and the picture is beginning to take shape. When you go to add a piece to the puzzle do you start by looking for a copy of an existing piece? Or do you look for a piece that can fit into one of the gaps? The answer is obvious. You might use the existing pieces to refine and differentiate the piece, but it would be counterproductive to look for a copy of a specific piece.
Obviously, comparing a software development team to a puzzle is simplistic. At the same time, if you want to add a person to the team that will make a meaningful improvement to the overall project, you will be better served to look at what is missing, as opposed to what you have. If your team already has a top-notch tester, but no one with domain experience, look to hire a domain expert. If your development team needs a database guru, don’t worry about whether the guru knows C#. Your team can teach him or her C#. You can teach them how to test. What you can’t teach is what you don’t know. So if you are missing some skill or knowledge, go and find someone with that skill or knowledge. If they happen to already have some of the other specific skills your project needs, great. Just don’t focus on those because your team can teach those skills. Focus on filling in your gaps, and keep looking for new gaps to fill. If you are going to risk hiring a new person, why not look to maximize the potential gain for everyone involved?