Sudhir has done a good job highlighting some of the higher level concerns, and the skill needs on a team so I won't focus on that. I'd instead like to suggest that Selenium should never be used as your only automated testing tool.
Selenium/Webdriver is a tool primarily useful for end-to-end style automation. While I have seen a small few developers wrap a few tiny almost unit UI tests around it, I do not feel it gives you your best bang for the buck. In fact if automation is a goal of your team you likely want to be very judicious and careful where you apply selenium. Building a framework around selenium, using page objects, and then maintaing the other parts of the framework, that over time will need revision as the application under test changes will consume a good bit of your test teams time.
Because of this you may want to find very specific types of tests to apply through the front-end with Selenium. This means your team will want to apply other frameworks and tools to more lower level tests. If you take a look at this blog post about inverting the testing pyramix, you'll see the same recommendation (http://nunoborges.com/nunoblog/2011/2/23/inverting-the-testing-pyramid.html) that you want to spend a lot more time with unit and functional level tests, and then less so on api, and GUI.
There are many reasons for this. Unit and functional tests are much closer to the code and thus are easier to setup quickly and isolate for behavioral testing. API Testing is also good, as it allows you to check out the under lying business logic in a smaller subset of integration tests. The UI Tests can also bring some value, but I warn you, they are going to be slow, and slower over time. I've seen suites that have had to be broken up to keep build times under thirty minutes or an hour. This is not uncommon when a vast amount of UI testing is being applied.
So because of this, you want to apply different test techniques at each level, and try to leverage the scale differences and speed you gain, so that your UI tests can do what they are best at, verifying the interface is working, and less on its functional aspects.