I understand there are tremendous pressures to save money. This guy can automate tests, make him a QA Automation Engineer. He'll create test cases, run them, and he'll automate them as well. It makes sense. After all, "QA" is in his title. It should be his responsibility. Or should it?
For QA you need the following abilities:
For QA Automation you need these abilities:
Which is another subject to talk about. Not every test case is worthy of the time it would take to automate it. Login tests for one, while logging in is a legitimate task, it's done by every user of the system. It can't fail without everyone knowing it. So what tests should be automated? I think this should be a Lead QA decision, but I'd start with tests that have found bugs. Especially if the test has found multiple bugs and different times in the life of an application. Multiple bugs at different times in the life of the app indicate either a design flaw or an area the developers might not understand well. These tests should be automated in order to guarantee they are run everytime there is a change to the system.
Other tests that could be automated might include more obscure system actions. If it doesn't happen often, but it's critical when it does is an immediate flag for automation. Not every functional test deserves automation. It's simply not worth the time provided there are plenty of unit tests and integration tests built during development, and in the case that there aren't unit or integration tests, automating test cases should be the least of your concerns.