Chapter 17. Leading through learning: the responsibilities of a team leader
I was honored when Roy asked me to explore the topic of team leadership. It’s an interesting topic because it can cover such a broad array of factors.
We could cover the usual things, such as servant leadership, impediment removal, or motivation, but there’s one thing that intrinsically sets great leaders apart from mediocre ones. To get there, we should first discuss the responsibility of a team member.
One of the things that excites me the most about the Software Craftsmanship movement is a shift of responsibility. Frequently we, as developers, have set out with the ingrained feeling that it’s our organization’s responsibility to help us grow and succeed. 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 were hired. You could look forward to staying with the company, putting in your best, and getting rewarded upon retirement with the knowledge that you’ll be cared for in return.
Those days are gone. I don’t know of any colleagues who’ve taken a job with a company thinking they’d be there for 20 or 30 years. That seemingly coincides with the mantra of “Here today, gone tomorrow,” which some organizations practice. That further means that, if we can’t even be sure that our jobs are still going to be here, we certainly can’t expect that it’s a given that organizations will help us grow.
As a part of the Craftsmanship movement, we’ve declared that we shouldn’t expect to be gaining knowledge from organizational initiatives or in the course of our 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.
In this book, Roy explores the questions each team leader should ask themselves. One key question, perhaps the hardest question for many leads to answer, is this: Is my team better than it was last week?
This approach is what has set my preferred leads above others. It doesn’t matter which industry—I saw it from software team leads as much as fire captains and other industries I’ve been involved with. 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) speak about starting up a company. He mentioned how feedback loops affect growth. If you’re single, and go up to someone and ask them out, one of three things will happen:
- They’ll say yes.
- They’ll say no (or some variant, like slapping you upside the head.)
- 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’re 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 emailed about.
Baffling, huh? Imagine if, instead, the team lead emailed you back and told you that they have concerns because you haven’t been involved with FooBar, and Senior Joe is going to take this initiative but will work closely with you so that you can jump on the next one.
Or, imagine the team lead replied and said, “Go for it,” and offered guidelines to measure your progress. Let’s say you took that and failed miserably, but, because of the team involvement, others were able to pick up the ball and help you 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 finance, but by passion that comes with the knowledge that the team is always greater than any one developer. It’s turning your day-to-day interactions into chances for growth and learning, and ultimately building a learning organization.[1]
See Scott Bellware’s blog entry “Learning Culture,” December 27, 2008, http://mng.bz/Qi11.
Team leadership is about setting aside your ego, your pride, to be able to go out and help others. Effective team leads aren’t generally the rock star developers who put in 70-hour weeks because they’re hard core. They’re solid technical leaders—and solid social leaders.
For example, Scott Bellware had an article on the Chief Engineer role[2] in which he described the responsibilities and qualities of the chief engineer at Toyota. These included
Scott Bellware, “Chief Engineer,” December 17, 2008, http://mng.bz/wJnJ.
- 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
If you’re 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’s telling you? Or are you constantly impatient for them to finish speaking so you can tell them the right answer? Most importantly, what actions are you taking today to make your developers—your team—better one week, one month, one year from now?
In the answers to those questions lies the growth path for you as a leader. Keep growing, keep questioning, and keep learning—and your team will too.
Roy’s analysis
This practice can and should be used as a fundamental way to approach the learning phase in a team.
The feedback aspect is interesting because you can map it to a couple of the influence forces I mentioned earlier in the book. When you give feedback to a team member on their behavior or actions, you influence them in at least three ways:
- Social ability— How people react to your actions.
- Social motivation— Assuming they respect you, then your line of thinking on improvement will affect their line of thinking.
- Environmental motivation— Your role as an appointed leader also signifies that from the organization’s standpoint, it’s recommended to learn new things, which is what the organization rewards. This can backfire if there are opposing rewards or influences.
CORY FOY is an agile coach and developer living in Bayonet Point, Florida. He’s currently helping product teams become leaner 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 two 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 www.cornetdesign.com or on Twitter at https://twitter.com/cory_foy.