The basic rule for any leader is simple: don't ask your team members to do anything you would not or cannot do. There are exceptions for obvious things: you're not a C++ developer but need C++ code to be done. But that's not what I mean. What this really means is don't ask them to work late without being willing to do it yourself. Don't ask them to come in on the weekend without being there yourself. Don't ask them to present without being willing to present, too, or at least be there for support. Don't ask them to skip their vacation without you changing your plans. And a whole lot more. The reason is to make sure the team understands that you are willing to do what you ask them to do, and you're not an elitist twit making stupid demands that can't be met.
Setting an example goes hand in hand with the most important leadership quality: respect. If the team knows you will work as late as they do, as hard as they do, and as well as they do, you will earn their respect. Without respect, there is no leadership possible. You become just a boss. So, when I teach leadership courses, one of the most important things I drill into students is the need to be omnipresent in the office, show that you'll roll up your sleeves just like they do. In fact, you should do more than they do. Lead by example, but make sure you lead.
From a technical point of view, this is relatively easy if you were in the ranks. Don't ask the developers to follow a process and then don't follow it yourself. The exact opposite: you should be a slave to the process, so that you can see how easy (or hard) it is to use, figure out how to make it better, and show that sticking to the process is not as bad as they think and can pay dividends. If you hear complaints from employees about the process, you can show that you follow it, perhaps have the same issues they have (or perhaps you've solved them), and you can work together to make things better. The excuse "I don't have to do it, I'm the boss" is totally inexcusable! Don't ask developers to write unit tests for their code if you can't write them for your code! (Which brings up the side subject: if you can code, you should! It will get you respect from developers faster than any other way. You may be a bit rusty but pick something simple and do it, without showing off. Just make sure it works properly!) If you are pushing the QA team to improve quality, dig in and do some testing yourself. Figure out how the testing process works and participate! I used to allocate an hour or two every night to running a few test cases, just so I knew what was going on with the software and the code base. It's the easiest way to get a feel for the developers and the testers quickly. If you can write, do so. Write technical specs, architecture overviews, product literature, whatever you can to help the team out. Show you belong from the technical point of view, not just as "a boss".
From the HR point of view, get involved in every hiring decision one way or another, even if just to sit in. When asking people to work extra hours, stay with them. Bring in snacks or goodies. Make your presence felt after hours and on weekends and make sure the people working extra time know that you appreciate the effort. Never demand something from your team you would not be willing to do yourself, or you risk losing respect and worse, derision behind your back. I had a few bosses in my early days in the telecom world that demanded we work weekends to meet their deadlines, but they were never seen after 5PM Friday. That lead to a lot of comments about the bosses' dedication!
From the company point of view, champion your team and show the rest of the company that your team will follow you and help as much as they can. Always use the "we" and not "they" pronouns. They succeed, give them credit. They fail, it's your fault. Set that example not just for your own team (they will hear about it, but they should not hear from you), but for the other teams in the company.
In all, you should be the first to put in overtime, put in the extra effort, take the extra steps to make customers and employees happy, and generally set the best example you can. Not everyone in your team will notice, and some won't care, but a lot will. And they will respond. And that's what leading is all about.