Writing secure code
Every developer writes code, but not every developer writes secure code. While it's not a skill many managers understand (or others, for that matter), developers who can not only write secure code but also mentor and teach other developers how to create secure code can be an invaluable team member.
Writing secure code is more than just worrying about obscure buffer-overflow attacks or race conditions. You've obviously seen by now my theme that more and more applications are Web apps, and increasingly those are also becoming SaaS applications in many cases. Web attacks are in the forefront of risks where good, secure software-development practices need to be applied. SQL injection, cross-site scripting, magic URLs and hidden forms, data leakage prevention, securing Web services, and bad implementations of SSL are all examples of security issues that software development must consider and accommodate when writing secure code.
If you're looking for some good resources to get you started down the path of creating secure code, I'd recommend two books 19 Deadly Sins of Software Security by Howard, LeBlanc and Viega, and Web Services Security by O'Neill.
QA automation and metrics
If you're a QA person, you've got a special place in my heart. If you're a QA person who lives to automate QA testing, capture metrics and use that data to improve software development and QA practices, then you've got a special place in heaven! As you can tell, I place a lot of value on high-quality QA skills, particularly those skilled practitioners who not only find all those nasty software bugs before any software gets out the door, but also know how to highly automate testing and use the knowledge gained to improve how software is created in the process. Software developers might be the lead singers and guitar players in the band, but as any experienced musician knows, it's the drums and bass that make or break the band. I like to say; love developers, and trust QA. (Actually, I love QA people too.)
Want to make yourself indispensable as a QA person? Automate, automate, automate. The best projects I've worked on had tests automated well into the upper 90%'s, and tests were run hundreds and hundreds of times before the software shipped. Now, that's what I call regression testing! New functionality might be tested manually, but tests were always automated before design was done on the next software release. That's about the only way CTOs and VPs of engineering are ever able get any sleep. Now, take that one step further and provide your peers, technical leaders and management with learnings and insights you're gaining from all that testing and you'll reach nirvana status in my book. The knowledge that's contained in all those test results can take even the best development organizations to new heights.