Team Leadership Guide¶

This guide contains advice, resources, and suggestions for leading teams at Stanford Code the Change. This guide is by no means complete (and it never will be), so please add your own knowledge to it so we can all learn to be better leaders!

General Leadership Principles¶

These ideas are applicable to leading in many contexts, including CtC teams.

Listening¶

Sometimes it might seem as if “listening” is trumpted as the cure for everything, but I think it is critical for leaders to be acutely aware of and sensitive to their team members’ needs, triumphs, and feelings.

Needs¶

Many of my mistakes in leadership were the result of underestimating my team’s needs or overestimating their abilities. For example, I have given my teams too much autonomy and responsibility before they were ready for it, and the result was confusion and wasted time.

To avoid this, you first need to be aware of your members’ needs. This might mean starting off each meeting checking in on how they are doing, both with respect to the project and more broadly as a person. If they tell you they are confused or lack direction, listen to and take seriously that feedback. For more long-term needs, I like to have quarterly feedback forms and live (e.g. in person or over the phone) conversations with each member to gauge what they are comfortable with and what they need help with. Once you know your members’ needs, you can take actions to address them.

Triumphs¶

Be wary of only thinking about the negatives–what your members are failing to do because of unmet needs. Also pay attention to when they succeed. When a member submits a pull request, for example, make sure to comment on the things they did well, not just the problems that need fixing. You don’t want to overwhelm them with negative feedback, and knowing what to do again is also super helpful. Also, you want to know not only when you are not giving enough help, but also when you are providing too much help. As teams grow more confident and competent, they will be able to move faster and with less guidance. Let them! Your team won’t be able to get better if you’re micromanaging the details they already have mostly handled. They instead need you to be exposing them to bigger-picture ideas like project planning and module organization.

Feelings¶

Even in a technical team, each member’s emotional state has direct impacts on the team’s work. Stressed-out members, interpersonal conflicts, and a loss of motivation can all prove fatal to a team, so you should pay attention to them. For example, once a team lead was worried about one of their members not feeling like they belonged in the club. Their concern is why our feedback surveys ask about belonging now, and it was also a driving force behind our efforts to recruit members with backgrounds that aren’t well represented in our club.

Response to Feedback¶

It’s not enough just to listen, though. You also have to do something with what you learn. In particular, it is often helpful to be open about the actions you are taking in response to feedback so that people know their suggestions will go somewhere. Be careful though not to violate the implicit confidentiality of feedback given in private. Breaking the trust of your members can also destroy a team.

Situational Leadership¶

This section on situational leadership is adapted from the training trip leaders receive from Stanford Outdoor Education (SOE).

Leadership Styles¶

Different styles of leadership are appropriate at different phases of group development and in different situations. In general, for a given problem, leaders progress through these styles sequentially as their groups mature. The more critical or difficult a problem, the more slowly a later leadership style will become appropriate. To take an example from Stanford’s Outdoor Education program, trip leaders adopt a more relaxed leadership style (delegating) quite early on for trivial decisions like what music to listen to. On the other hand, leaders take much more control (directing) in emergencies regardless of the group’s maturity or experience.

Directing: A directive leader is more authoritative. They direct members on what to do next, and they provide near-constant oversight and guidance. While this leadership may seem over-bearing, it’s actually critical when groups are new or inexperienced. These kinds of groups are often comforted by knowing (a) that someone is in charge and (b) exactly what they are supposed to do. Setting clear expectations and a good example are critical here because this early stage is when the tone and culture of the team are set.
Coaching: As teams become more comfortable in their work, a leader can step back a bit and let members learn by doing. Teams are generally not yet able to work on their own, but they are comfortable enough to try. Here, leaders should support that desire to try and learn. Members will still need lots of guidance, but they also now need to see the big picture–the why–to motivate their work. Leadership here should focus on being transparent in how decisions are made, answering questions, reinforcing good practices, and pointing out ways to improve. Note that the big difference between directing and coaching is not in ability but rather in comfort. Members probably aren’t that much more capable than in the directing phase, but they’re comfortable enough to play a more active role by trying and learning.
Supporting: This is where a group’s capabilities grow. Members are beginning to have the skills to work independently, but they haven’t mastered them (not that any of us have!), and they still need help with tricky parts. After setting the initial direction, a leader here can often step back and provide targetted guidance and help as needed. Now a leader is more focussed on encouraging and participating alongside members rather than being apart from the other members. A leader here will still need to step in sometimes to help though; it’s just that that intervention isn’t constant anymore.
Delegating: This is when a group is essentially autonomous and a leader can pretty much step back and let members do their own thing. This can be immensely empowering for the group, but it can also end badly if the group runs into problems or disagreements without a leader to step in. Here a leader is more of an equal member of the group, but they are still watchful for potential problems that may need them to step in and assert more control.

This section on leadership styles was adapted from page 5 of the Outdoor Leadership section of the SOE 2017-2018 Field Guide.

Self-Awareness¶

The example you set as a leader is one of your most effective leadership and teaching tools. Especially with new groups, group members tend to immitate the example set by their leader. Therefore, make sure you are engaged, courteous, and respectful whenever interacting with group members. That can make the difference between someone feeling included and feeling like they don’t belong.

Learning who you are as a leader comes largely with practice, but here are some suggestions:

Be mindful of your own emotional state. If you’re frustrated, it’s likely your team will pick up on it. This is especially important when resolving conflicts, as you can’t diffuse tension if you’re not calm yourself.

Keep a close watch on what you find challenging as a leader. It might be that you have a hard time giving directions, accepting criticism, or responding to questions you don’t have an answer to. Notice them and focus on improving them.

Especially with new groups, don’t be afraid to be “in charge” and directive. It can be difficult to give instructions to a bunch of your peers, but your team needs you to lead.

At the same time though, be attentative to how your team is feeling. You also don’t want to be demanding or establish a poor relationship with your members. Leadership requires mutual trust.

There’s a balance to be struck between giving groups instructions (e.g. “go learn this framework using this website”) and letting them learn on their own (“here’s a problem, see if you can figure it out with Google”). The former is important for setting a good technical foundation, but the latter is way more fun if a team is ready for it. There’ll probably be some trial and error here as you figure out what each of your members is ready for.

Conflict Resolution¶

Conflicts will eventually arise in any group, and they will sometimes become disruptive. Leaders need to step in to resolve those disruptive conflicts, and it may be appropriate to also resolve conflicts that have the potential to become disruptive.

The EAR Method¶

When reading this method, you might feel like it’s an over-the-top response to the kinds of simple disagreements we encounter everyday. However, consider what you do when disagreeing with someone. You probably listen to their position, explain what you want, and try and reach some common understanding. The EAR method is just a formalization of that technique. Why bother with the formality? As a leader, the pressure to “lead” and fix the problem can destroy the calm and empathy dispute resolution requires. Following a formalization, even loosely, can help you cut through the pressures and clear your judgement.

Use the mnemonic “EAR” to remember these steps:

Listen In: Take a moment to evaluate your own mental and emotional state. Are you calm? You’ll need to be composed and level-headed to resolve the situation. Stepping in when you’re angry or upset could inflame tensions even more.

Listen Out: Evaluate the situation before stepping in. What is the context within which the conflict has arisen? Has the team been frustrated working through a difficult task? Is everyone stressed about their classes? You won’t be able to figure out the cause of the conflict yet, but the “environmental” factors you notice can help you understand later on. (This is unlikely to be an issue for CtC, but in other contexts, like SOE, you might also need to consider whether the conflict poses safety issues and therefore necessitates an immediate resolution.)

Express: Let each party to the conflict express their view of the situation. It is important for everyone to know that their views and position are being heard, so everyone needs to actively listen. This is also a time to diffuse the emotion of the situation, so parties should be asked (and reminded if necessary) to speak only for themselves and avoid insults. “I” statements can be helpful here (e.g. “You’re being lazy” becomes “I feel like I’m doing more work than everyone else, and I don’t feel that’s fair”). Everyone, including you, should be listening here, not judging.

Address: You summarize the situation, including everyone’s concerns, out-loud to the group. Try to be as fair and neutral as possible here, as the point is to make sure everyone understands what the problem to be addressed is. It also serves to make the conflict a problem to solve, so the group should also discuss potential solutions. The point here is to figure out a solution that satisfies everyone’s needs, not to pick a winner and put the blame on a loser.

Resolve: The leader now suggests or adopts a plan to resolve the conflict. It may require a compromise where each party has to give something up, but it should be neutral and rational. The group then discusses and tweaks the plan so that everyone feels as good about it as possible. It is important for everyone in the group to accept the plan.

Thank you to Sam Spinner for teaching me this method during an SOE training trip. It is adapted from the curriculum used by the Boy Scouts of America. See this link for more information.

Building Community¶

This section will focus on ideas for promoting a few selected values that you might want to promote in your team.

Collaboration¶

Consider the challenges to collaboration for a new team. Your members probably don’t really know each other, and at least some of them are probably newcommers to some of the technologies you will be using. To build a collaborative team environment, you will probably need to address both of these barriers.

Helping Strangers Collaborate¶

At its core, this is just a question of how to help strangers get to know each other. (Let’s assume you’re not trying to promote a more distributed open source model where collaborators don’t actually need to know each other.) Doing introductions and talking with your members will help. Your example as a leader can be very powerful here, for example by addressing your members by name and chatting with them. You’ll probably have to do introductions multiple times, as your members are unlikely to memorize names right away. Another strategy is to get your team to work in pairs, perhaps on their first tasks. This gives them a chance to get to know one other member in more depth, and it has the added benefit of making the task less intimidating. (Also, it’s harder to show up without having done anything when you have a partner relying on you!)

Helping Newcommers Collaborate¶

A common motif in new teams is your team having pretty much no idea what you’re saying but none of them wanting to seem ignorant by asking. However, you need them to understand what the basics for them to be able to start working on anything. One solution to this conundrum is to directly teach the basics and do so at a very elementary level. Remember that you probably have some members with next to no experience. Be wary of using jargon like “API”, “frontend”, “token”, “framework”, etc. One technique is to, as a first “assignment,” have your team pick various technologies you’ll be working on to learn about. (Make sure everything important gets covered either here or by you!) Then, they can all present their findings at the next meeting to help bring everyone up to speed. If all goes well, most of your meeting will be answering questions as your team learns.

Support¶

Your team will probably be much more effective if members support each other and feel supported. This has many dimensions, from the emotional to the technical. Here, we’ll focus on building a culture of technical support. Overt encouragement can help here, for example by encouraging people to send questions they have or problems they run into to the whole group (e.g. via Slack). You can also set an example of being available to help and quickly responding to member questions and problems. This might mean searching the documentation for someone’s question, or it might mean meeting up with someone to debug their code. As time goes on, hopefully other members will start taking over and helping each other.

Licensing and Attribution¶

This work is licensed under a Creative Commons Attribution 4.0 International License.

This work was initially created for Stanford Code the Change.