Editor's note: The following is a guest post from Cory Foy. Cory Foy is an agile coach and developer living in Bayonet Point, FL. He is currently helping product teams become much more lean in their approaches to building product through the focused use of both craftsmanship and agile practices and principles. Prior to his current role, Cory worked with teams around the globe bringing agile and development best practices to Microsoft customers as a Senior PFE. He has also been involved in several start-up organizations where delivering high value while keeping the code clean is vital. When not spending time with his wife and 2 girls, Cory enjoys working as the global community liaison for the Scrum Alliance, speaking at conferences and user groups, and playing guitar, drums, or whatever he can get his hands on. He can be found at http://www.cornetdesign.com or on Twitter athttp://twitter.com/cory_foy (@cory_foy)

I was honored when Roy asked me to explore the topic of Team Leadership for the Five Whys blog. And it's an interesting topic too since it can cover such a broad array of things.

And while we could cover the normal things (Servant Leadership, Impediment Removal, Motivation) there is one thing I think intrinsically sets great leaders apart from mediocre ones.

To get there, we first should discuss the responsibility of a team member.

One of the things that has excited me the most about the Software Craftsmanship movement is a shift of responsibility. So many times we as developers have set out with the ingrained feeling that it is our organization's responsibility to help us grow and succeed. And this was true to some extent in the early days - great programmers stayed with great companies for a long time.

Growth was something you expected when you got hired in. You could look forward to being somewhere, putting in your best, and getting rewarded by retiring with them and being taken care of in return.

But, by and large, those days are gone. I don't know of any colleagues who have gotten hired with a company thinking that they would be there for 20 or 30 years. Which seemingly coincides with the mantra of "Here Today, Gone Tomorrow" some organizations practice. Which further means that if we can't even be sure that our jobs are still going to be here, we can't certainly expect that organizations will help us grow as a matter of normalcy.

So, as a part of the Craftsmanship Movement, we've declared that one shouldn't expect to be getting knowledge from organizational initiatives, or in the course of their role on a team. In fact, the core of the movement is that developers need to be taking responsibility for their own careers - learning, teaching, mentoring, speaking.

So what does that have to do with team leadership? Back in June, Roy posted an article called Questions every team and dev lead should ask themselves. In it, there was one key question that is perhaps the hardest question for many leads:

Will my developers be better in a month or two than they were before? If not, how do I make that happen?

This question, above all others, is what has set the leads I lift up above others. It doesn't matter the industry - I saw it from software team leads as much as Fire Captains and other industries I've been involved in. How do I create learning opportunities that enable my team to grow?

This past weekend I went to BarCamp Tampa Bay and got to see Steven Bristol talk about starting up a company. In it, he mentioned how feedback loops affect growth. If you are single, and go up to someone and ask them out, one of three things will happen:

1. They'll say yes
2. They'll say no (or some variant, like slapping you upside the head)
3. They'll turn around and walk away without saying a word

Out of the three, which will you learn the most from? Which will cause you to grow the most? Which will leave you scratching your head?

Imagine now that you are a developer on a team. You email your team lead and ask about taking on a new initiative for the team. The next afternoon an announcement is made that one of the senior developers is going to be working on the initiative you just emailed about.

Baffling, huh? Imagine if, instead, the team lead emailed you back and told you that she had concerns because you hadn't been involved with FooBar, and so for this initiative Senior Joe was going to take it, but to work closely with Joe so that you can jump on the next one.

Or imagine the team lead replied and said go for it. And offered guidelines so you could know what kind of progress you were making. And let's say you took that and failed miserably. But, because of the team involvement, others were able to pick up the ball with you and help get it done.

That's what you want from a team lead. This, in many ways, is the essence of leadership. Providing opportunities for people to fall, but always within the context of the safety net of the team. Motivating not by fear, or by money, but by passion that the team is always greater than any one developer can be. It is turning your day to day interactions into chances for growth and learning, and ultimately building a Learning Organization.

It also means setting aside one's ego, one's pride to be able to go out and help others. Effective team leads aren't generally the rockstar developers who put in 70 hour weeks because they are Hard Core. They are solid technical leaders - and solid people leaders.

For example, Scott Bellware had an article on the Chief Engineer role in which he described the responsibilities and qualities of the Chief Engineer at Toyota. These included:

• Voice of the customer
• Architecture
• Exceptional engineering skills
• A hard-driving teacher, motivator, and disciplinarian, yet a patient listener
• An exceptional communicator
• Always ready to get his or her hands dirty

So if you are thinking about leading a team, or finding yourself thrust into that role, ask yourself - are you growing? Are you seeking opportunities for yourself? For the team? Are you listening - truly listening - to what your team is telling you? Or are you constantly impatient for them to finish so you can tell them the right answer? And, most importantly, what actions am I taking today to make my developers - my team - better one week, one month, one year from now?

In the answers to those questions lie the growth path for you as a leader. Keep growing, keep questioning and keep learning - so that your team does too.