--- title: "Leading Through Learning: The Responsibilities of a Team Leader" url: "https://www.5whys.com/articles/leading-through-learning-the-responsibilities-of-a-team-lead.md" canonical: "https://www.5whys.com/articles/leading-through-learning-the-responsibilities-of-a-team-lead.html" published: "2009-09-30T20:51:36+00:00" updated: "2009-09-30T21:04:16.113000+00:00" tags: ["Growing People", "Guest Post", "Self Improvement"] author: "Roy Osherove" description: "Cory Foy argues that the core responsibility of a team leader is growing people, creating learning opportunities with the team as a safety net." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Leading Through Learning: The Responsibilities of a Team Leader > **Editor's note:** The following is a guest post from [Cory Foy](http://www.cornetdesign.com/). 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](http://www.cornetdesign.com/) or on Twitter at[http://twitter.com/cory\_foy](http://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](http://weblogs.asp.net/rosherove/archive/2009/06/16/questions-every-team-and-dev-lead-should-ask-themselves.aspx). 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](http://barcamptampabay.org/) and got to see [Steven Bristol](http://b.lesseverything.com/) 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](http://blog.scottbellware.com/2008/12/learning-organization.html). 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](http://blog.scottbellware.com/2008/12/chief-engineer.html) 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. ## Read next - [Check-in: sharing emotions in an effective way](https://www.5whys.com/articles/check-in-sharing-emotions-in-an-effective-way.html): Yves Hanoulle explains the Check-In protocol from The Core Protocols, using mad, glad, sad and afraid to share emotions at work and at home. - [The Core Protocols Introduction](https://www.5whys.com/articles/the-core-protocols-introduction.html): Yves Hanoulle introduces The Core Protocols, team rules Jim and Michele McCarthy distilled from their team-building workshops, and invites you to try them. - [The Fear Of Failure And What To Do About It](https://www.5whys.com/articles/the-fear-of-failure-and-what-to-do-about-it.html): Using a Milton Glaser video on the fear of failure, a look at why team leaders must take personal risks and how timed experiments can lower them. --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/