A few thoughts based on my not-quite-ten years experience as a tester and automator:

• Learn the principles, not a tool - If you understand the principles of automation and how it works, you're going to be in a much better strategic position than if you simply learn an automation tool. You could do worse than to dig through Joe Strazzere's blog and Alan Paige's blog for some interesting insights into test automation as well as test management in general.
• Understand different automation levels and techniques - Test automation can be performed at multiple levels, from unit tests (which should be written by developers and run with each build) through various forms of integration, module, and API tests, to GUI-level tests. If you understand the pros and cons of each kind of automated test, and where you'd choose one over another, your automation specialists will worship at your feet (maybe not literally - but having had to educate a number of leads on this topic, I can say that someone who gets it is very welcome addition to a team).
• Understand the different purposes of test automation - Test automation can happen for a number of reasons. A lead/manager who knows and understands them is someone many testers love to work with - because they aren't having to justify "unproductive" time (yes, I've had this...). The most common, and what you'll see a lot of here is functional and GUI-based automation used for regression testing. Most of the big-box tools are geared towards this, and most of them use record-playback as their selling point. Which leads to my next point:
• Record-playback should be consigned to the deepest pits of hell - It makes fragile tests that are hellish to maintain. The main reason record-playback is such a big selling point is because it makes it easy for someone with no programming background to create a whole lot of tests quickly. When I use record-playback, I use it solely to get object handles I can manipulate programmatically: this is the only valid use for record-playback in my opinion, and a decent object inspection tool can do the same job.
• Automation is programming - This should be obvious to a professional with your level of experience, but it's worth repeating anyway. Automation is programming, and automation code needs to be subject to similar levels of inspection, code review, and code standards as production code. It's got to stop somewhere, of course, or you have tests to test your tests of the tests of the test code, but code review of all new test code and regular review of the tests being run is a must. Don't be afraid to deprecate tests that are no longer relevant, either: automation is a resource-intensive activity, and maintaining test code that's not being used in production is a waste of everyone's time.

A few thoughts based on my not-quite-ten years experience as a tester and automator:

• Learn the principles, not a tool - If you understand the principles of automation and how it works, you're going to be in a much better strategic position than if you simply learn an automation tool. You could do worse than to dig through Joe Strazzere's blog and Alan Page's blog for some interesting insights into test automation as well as test management in general.
• Understand different automation levels and techniques - Test automation can be performed at multiple levels, from unit tests (which should be written by developers and run with each build) through various forms of integration, module, and API tests, to GUI-level tests. If you understand the pros and cons of each kind of automated test, and where you'd choose one over another, your automation specialists will worship at your feet (maybe not literally - but having had to educate a number of leads on this topic, I can say that someone who gets it is very welcome addition to a team).
• Understand the different purposes of test automation - Test automation can happen for a number of reasons. A lead/manager who knows and understands them is someone many testers love to work with - because they aren't having to justify "unproductive" time (yes, I've had this...). The most common, and what you'll see a lot of here is functional and GUI-based automation used for regression testing. Most of the big-box tools are geared towards this, and most of them use record-playback as their selling point. Which leads to my next point:
• Record-playback should be consigned to the deepest pits of hell - It makes fragile tests that are hellish to maintain. The main reason record-playback is such a big selling point is because it makes it easy for someone with no programming background to create a whole lot of tests quickly. When I use record-playback, I use it solely to get object handles I can manipulate programmatically: this is the only valid use for record-playback in my opinion, and a decent object inspection tool can do the same job.
• Automation is programming - This should be obvious to a professional with your level of experience, but it's worth repeating anyway. Automation is programming, and automation code needs to be subject to similar levels of inspection, code review, and code standards as production code. It's got to stop somewhere, of course, or you have tests to test your tests of the tests of the test code, but code review of all new test code and regular review of the tests being run is a must. Don't be afraid to deprecate tests that are no longer relevant, either: automation is a resource-intensive activity, and maintaining test code that's not being used in production is a waste of everyone's time.