I've been reading several books on the process of software development and management of late (see reading list below) and have begun trying to determine the nature of my own management philosophy. This is an ongoing process in my head, but below are some of my initial thougts (summarized predominantly in platitude-ish sayings, because even though my inner snarker hates them that's how my mind works).
Hopefully the team I work with wont read this and feel that my behavior is not consistent with these. I think this how I actually do things, but I'm as fallbile as anyone.
I fail. The team wins.
As a team lead, at the end of the day, I'm the one finally responsible for making sure what we produce meets specification in terms of quality, delivery time, and budget, but I'm not (usually) the person with hands on the keyboard building out the product. Because I'm not the person actually building things, I cannot fairly claim the credit when the product development effort is successful. But at the same time, as the one with final resonsibility, I do have the onus to take the blame if the effort fails.
So when the client is happy, it's my duty to pass the glory to the team members who actually did the work. But when the client is pissed, I should be the one who takes the heat. (This is not to say, though, that I will not subsequently give heat to those more directly responsible. The difference is that the heat the developers get should come from me, not from the client.)
This is not to say that I should get no credit for success. If those I report to are worthy of the title of manager, they should be able to see my efforts in the success of my team. (So maybe another way to summarize this is that the team succeeds at doing things and I succeed at helping the team succeed?)
My job is to work my way out of a job
If the team can't get along without me, I'm not doing my job. The team's processes should be sustainable and self-directed to the point that I do have to guide them on a day-to-day basis. If that's not the case, I have failed to either establish meaningful processes or to train the team on how to carry out those processes.
In the same fashion, the team should not need to come to me frequently to answer "how-to" questions. The mentoring part of my role should be helping guide the members of the team to being able to solve problems on their own. Socrates did not simply tell his students what the answers were, he asked questions to help them draw out the answers on their own. When devs come to me with questions, I should be helping guide them to the answers in the same way so that they not only find the answer to the immediate question but learn the process for thinking through problems so they can resolve the next question on their own. (I recognize this is probably at times annoying as heck to the team. Sorry guys, but I'm probably going to keep answering questions with questions.)
Fear is adaptive
This one is maybe less management-y than general process, but there are times when you, as a developer, absolutely should be afraid. Fear's entire purpose is to make you cautious. When you're about to launch a new site or make changes directly in the production database you should definitely be afraid. The trick is to think through the fear and let it make you cautious and circumspect in your actions rather than letting it paralzye you or lead you into errors. In these situations, slow down, think, and act deliberately.