Team leader Roles and Responsibilities (2019)

Team leader Roles and Responsibilities

20+ Team leader Roles and Responsibilities

A good team leader takes responsibility for your team performance as well as its behavior. A good team leader has many Roles and Responsibilities acts as a quality inspector and motivator that help team members every stage.

 

Team leader Role and Responsibility 1:

Review the Code

Review Code

One of the biggest mistakes that new software team leaders make is to consider the code written by the programmers as the private property of the author, as opposed to an asset owned by the team. This causes the team leaders to judge code based on their behavior rather than its structure. 

 

Team leaders with this dysfunction will accept any code so long as it does what it is supposed to do, regardless of how it is written. Indeed, such team leaders often don’t bother to read the other programmers’ code at all. They satisfy themselves with the fact that the system works and divorce themselves from system structure.

 

This is how you lose control over the quality of your system. And, once you lose that control, the software will gradually degrade into an unmaintainable morass. Estimates will grow, defect rates will climb, morale will decline, and eventually, everyone will be demanding that the system is redesigned.

 

A good team leader takes responsibility for the code structure as well as its behavior. A good team leader acts as a quality inspector, looking at every line of code written by any of the programmers under their lead. A good team leader rejects a fair bit of that code and asks the programmers to improve the quality of that code.

 

A good team leader maintains a vision of code quality. They will communicate that vision to the rest of the team by ensuring that the code they personally write conforms to the highest quality standards and by reviewing all of the other code in the system and rejecting the code that does not meet those exacting standards.

 

As teams grow, good team leaders will recruit lieutenants to help them with this review and enforcement task. The lieutenants review all the code, and the team leader falls back on reviewing all the code written by the lieutenants and spot checking the code written by everyone else.

 

The code is a team asset, not personal property. No programmer should ever be allowed to keep their code private. Any other programmer on the team should have the right to improve that code at any time.

 

And the team leader must take responsibility for the overall quality of that code. The team leader must communicate and enforce a consistent vision of high quality and professional behavior.

 

Team leader Role and Responsibility 2:

Document Everything

Document

Think about all of the things you need to know when you’re new to a team. There are a lot of things, right?

  1. Where is the source code repository?
  2. Which tools need to be installed on your developer environment?
  3. What are the steps to build the product?
  4. Is there a pattern for how the code is laid out in the repository?
  5. How are tasks tracked?
  6. What is the task branch pattern in the repository?
  7. Where is the continuous integration server?
  8. Are there any specific development methodologies that should be followed?

 

Many times, the answers to these questions aren’t actually documented anywhere. It’s “tribal knowledge.” People just sort of “know” what needs to be done, and if you don’t know, you ask the group.

 

That sort of approach might work well in a small group that doesn’t change a lot… but what about in a larger group? Does everyone actually know? Or is there a slightly different understanding of how things work from person to person? And what about new team members?

 

Why document?

Why document

Enable team members to help themselves. It’s generally understood² that “quick questions” causing team members to task switch are actually not as “free” as one might think³. If there’s a place that folks can go to answer simple questions, it reduces context switches, particularly when there are newer members on the team.

 

Give new team members confidence in the team. Last time you joined a team, how was the experience? Did it seem a little jarring or was it really smooth? When you’re new to a team it’s like meeting a person for the first time… and you only get one chance for a first impression.

 

Wouldn’t it be nice to join a team and have the reassurance that there are a plan and a simple document that lays out everything you need to know to get going? If you saw that, wouldn’t you gain a little confidence in the team?

 

Add visibility to your team. If there are other people or teams in your company that are interested in seeing how you’re doing things (maybe to learn something from your team?), having a document makes it easy for them to see how things are done and understand what they’re looking at.

 

How do you get started? How do you maintain it?

1. Find a location. Find a central place on your company’s network that you can store the document such that everyone has access to it. Maybe it’s a wiki. Maybe it’s a SharePoint site. Maybe it’s a simple file share. As long as everyone has access to it, it’s perfect.

 

2. Document as you get asked questions. As people have questions about how the team works where the source code is, and so on, refer them to the document.

 

If the answer isn’t there, consider adding the answer to the document and providing the document to the person asking the question. Eventually, you’ll have a document with the answers to the most frequently asked questions about the team.

 

3. Pass it by existing team members. Team members come in, and team members move on. Before a team member moves on from the team, part of the knowledge transfer should be having them review the document and fill in applicable answers. There may be some things that team member was responsible for that no one else really knows about.

 

4. Give it to new team members. When a new member comes on board, give them the document as a way to get them set up. It will quickly become apparent if the information on the document is incomplete.

 

When incomplete/incorrect information is encountered, have the new team member work with the team to find out the correct information and update the document.

 

5. Update as changes occur. As changes are made in the way the team works, update the document to reflect them. There shouldn’t be so much information there that it’s overwhelming to maintain, but the doc does need to be a living entity, just as your team is.

 

Make sure to keep your document fairly lightweight and easy to maintain. If it’s too thick or complex, if the information is repeated in multiple places throughout, people will skip updating it and eventually it will become stale. You don’t want that you want it to be easy so when it’s time to update, it’s simple, simple, simple.

 

It doesn’t take much and it pays off in spades. Why not start today?

I personally have experience of written evaluations where the employee has no input, various rating systems where both employees and managers get to rate the individual, and written appraisals where the employee makes comments on their own performance that are then used as the basis for further discussion.

 

Some systems have been directly linked to pay and promotion opportunities whereas some have been explicitly decoupled.

 

One thing that they all have in common is that they focus on the individual, their performance, and what they’ve accomplished since the last review period.

 

They encourage the individual to take credit for themselves and to compete against the other people on their team for recognition and a limited pot of money when it comes to bonuses and salary increases.

 

I would suggest that this is in direct conflict with the adoption and use of agile frameworks within the organization.

 

Agile emphasizes teamwork and co-operation in order to successfully deliver a product, with individuals being prepared to take on any task that needs doing in order to complete the iteration and get to “done.”

 

Individual accountability, as valued by the traditional appraisal system, implies that individuals should be interested in taking the juiciest or most challenging tasks for themselves in order to prove their worth and progress within the organization.

Agile processes

Agile emphasizes the forming of self-organizing teams who direct and manage their own work, whereas appraisals involve the setting of objectives that traditionally come from the manager.

 

Agile processes emphasize continual process improvement and, while this can be done alongside traditional appraisals, appraisals are geared more toward making individual or process changes at review time.

 

Is there a case for abolishing appraisals altogether in an agile environment? Well, perhaps. The challenge is that individuals within an organization expect and deserve feedback on their performance.

 

Perhaps a step in the right direction would be for team leaders to make the appraisal process itself more agile and encourage an environment where the annual review is replaced or supplemented with a system of continuous feedback and learning where individuals—in line with agile—are empowered to self-organize their own career development. Here are some ideas to get you started:

 

Build learning and career development into individual user stories, perhaps in the form of a specific task that involves team members expanding their business domain knowledge.

 

Alternatively, include time for learning tasks into your velocity calculations so you can increase the “value” of each team member to the organization by expanding their skill set in a way that’s relevant to their immediate task. Let the individuals drive and organize this learning process as they would a normal development task.

 

Encourage pairing (pair-programming for example) on tasks that help individuals to learn from those more experienced than them. Include team member feedback sessions as part of your iteration retrospective process, where you can directly discuss what people have learned.

 

Encourage individuals, on an iteration-by-iteration basis, to maintain a body of evidence that can be directly referenced at formal appraisal time. This will reduce the time taken to plan and perform the appraisal and encourages the recording of tasks at the time they happen—when they’re most relevant.

 

Team leader Role and Responsibility 3:

Leading Through Learning

Team Leader

I was honored when Roy asked me to explore the topic of team leadership. 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 have 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, those days are gone. I don’t know of any colleagues who have gotten hired by a company thinking that they would 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 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.

 

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 the 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?

 

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 have you 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 leader. 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 the 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 rock star developers who put in 70 hour weeks because they are hardcore. 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:

  1. Voice of the customer
  2. Architecture
  3. Exceptional engineering skills
  4. A hard-driving teacher, motivator, and disciplinarian, yet a patient listener
  5. An exceptional communicator
  6. 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 lies the growth path for you as a leader. Keep growing, keep questioning and keep learning–so that your team does too.

 

You should change your mind about what you are building when you become a project manager or team leader (as a boss). Forget your product. Look at your team. Suddenly, you do not have to worry about technical decisions or pretty interfaces. You must realize that the basics of your work have changed. My own inspiration is the mantra “team = product”.

 

The product will be as good as your team is. The behavior of your team will determine the qualities of the product. So, your product as a project manager is the team. Invest in the team. This will change dramatically your efforts, now redirected to make the team grow.

 

Start changing your focus. From product to the team. From technology to people.

Pay attention to people and identify the phase in which your team is and what it needs to evolve. Find the right leadership at the time, but admit you can not get to become the leader, but only that person who turns mediocre teams into great teams, a great manager.

 

If you keep thinking about building products, these will be only as good as you were able to create managing and controlling your team. However, if you facilitate the emergence of the full potential of your team, the product will be enhanced and enriched by many people and their synergies.

 

Team leader Role and Responsibility 4:

Evolving from Manager to Leader

 Manager to Leader

Being only a manager will produce good results. But evolving into a leader first that has the capability to manage will produce empowered teams that achieve awesome results. Don’t even bother thinking it; not only are you are not a leader today, but you also won’t be able to change something tomorrow and immediately become a leader.

 

Your evolution from a manager to a leader will be primarily based on a combination of two assets. The first one is your ability to adapt and handle any risk or issue. Your high dependability was not a result of problems never occurring but how you were able to effectively minimize impacts and leverage opportunities appropriately.

 

The second one is your passion and skill for coaching and mentoring. And you’ve already experienced that people appreciate when you invest in helping them grow.

 

You’re lucky—adapting and the desire to help others comes naturally to you. But there’s a catch; to be aware and possess these assets will not be enough. You have other core traits that you often rely on that impact teams from being empowered.

 

Specifically, you will need to lessen the desire for being the go-to expert and wanting perfection. For example, you’ve already learned that responding to a problem on the team with “I should just fix that myself ” will not scale.

 

However, you’ve only adjusted the response to, “What didn’t I teach them to avoid this problem?”, which means that you expected your team to be perfect through your help.

 

Now don’t go overanalyzing with a thousand examples of why they could have avoided a problem. There absolutely is a time and a place for coaching as this is the important capability to manage aspect.

 

The problem is the leader mindset has to be the first impulse, which requires a response of “How can I help them learn and adapt from this?.” Your focus has to be in creating an environment that is dedicated to helping teams and individuals become adaptive, learning-focused, and cohesive.

 

There’s no sugar-coating the amount of work becoming a leader will take. You will have to maintain the skills necessary to have the capability to effectively manage.

 

At the same time, begin with the work required to build trust both ways in order for people to be empowered. As this will be the easier part given your integrity and intentions are pretty visible and we all know you have no issues talking.

 

The trick is in remembering that numerous situations are usually required before you will trust that they can adapt and more importantly, they fully believe that you trust them to adapt. Then tackle the challenging work that will drive you crazy; embracing failure as a learning opportunity despite knowing it could have been prevented.

 

You will have to constantly remember that your perspective should be on them; what’s best for their growth even when you and/or they might look bad in the process.

 

But the factor that really makes the answer so obvious is the satisfaction from helping others. The recognition you are receiving today pales in comparison to what you will experience as a leader. I still smile when I think about the time my team surprised me with an appreciation award.

 

To hear numerous people stand up and highlight these types of statements: “I appreciate the way she pushes me out of my comfort zone in a way that makes me feel supported” to “I appreciate how she calls me out on my BS” all the way to “I appreciate her helping to pick out gifts for my wife.”

 

I couldn’t help but walk out of that conference room proud of my team and, consequently, proud of myself too because I helped create an environment that I want to work and play hard in every day. That is worth everything!

 

Team leader Role and Responsibility 5:

Entrepreneurial Leaders

Visionary Leaders

In the previous section, we looked at how (negative/less than flattering) traits of the senior leader can damage the sales team. Let’s shift gears and examine how, surprisingly, sometimes the greatest strengths of the entrepreneurial, charismatic executive can actually impede a sales team’s success.

 

Your People Are Not You

One of the reasons I absolutely love what I do to earn a living is because I get the opportunity to work with some incredibly gifted people. My notes for this blog include a list of ten super-talented, visionary business leaders.

 

These senior executives have produced some of my most fun projects and client relationships because they often have boundless positive energy and are continually a step or more ahead of their team and me.

 

These idea machines dazzle us with their ability to create and improvise on the fly, to sell concepts that don’t yet exist, and to paint exquisite pictures of a brighter future to any audience.

 

That’s the good side of working for such a talented charismatic leader. However, there is a downside that is much more difficult to discern. Only after observing the same problem in multiple organizations was I finally able to recognize and begin calling it out to help clients identify and overcome the issue.

 

Several years ago, I was sitting with an extremely driven, extroverted, and charismatic CEO at the big glass conference table he used as a desk. It was our first meeting. I was entertained, amused, and even a bit shocked at his level of intensity and charm. His personality filled the room—in a good way.

 

I loved everything about this guy, including his cool shoes. And as he explained his vision for the company and the various major initiatives he was undertaking, I began to get a sense for the monumental task he was asking of his salespeople. The specific details aren’t important to the story.

 

What’s key to my point is how many moving pieces there were, and that this hugely talented sales chief was asking the sales team to sell a solution that was still on the drawing board to people and prospects who were unfamiliar and didn’t yet understand how to buy this type of new offering.

 

Said differently, he was asking people who had never sold this type of solution to sell something that didn’t truly yet exist to clients who weren’t quite ready, even though they would likely be looking for this type of solution in the future. Got it?

 

One of the reasons I was sitting across the big glass table from this man was because of his growing frustration that the sales team wasn’t getting it done. In three different ways, he told me that he couldn’t comprehend what was so hard about what he was asking his salespeople to do.

 

With each example, he’d tell me the story of a major sales success from his own career and how he was able to sell giant, transformational deals with essentially smoke and mirrors.

 

At that instant, the penny dropped and it all came together in my mind. I raised my eyebrows and began to smirk. In his loud, playful voice he shouted not to hold out on him. “What? Tell me!” he insisted. “[CEO Name], don’t you see what’s happening?” I responded.

 

“They’re not you! They can’t do what you can do. You get away with it because of the force of your personality, you're outrageous, a probably dangerous level of confidence, and your sick ability to sell a vision.”

 

What’s even more surprising is how many times I’ve seen similar situations in other organizations run by supremely gifted, charismatic entrepreneurs.

 

Team leader Role and Responsibility 7:

Feeding Back

Feeding Back

Feedback, especially positive feedback, is normally a sound engineer’s nightmare. A skilled guitarist can make it part of the performance, part of the music.

 

For software engineers, offering and taking feedback, positive or negative, can be just as much a minefield. When there is a problem, it is too easy to resort to silence or complaint. When there isn’t a problem, it is too easy to resort to silence.

 

Part of team leadership involves leading by example, but part involves guidance. For simple systems, guidance is programmatic, a matter of command and control. This doesn’t work well for complex systems, and individuals and teams are very complex systems indeed.

 

Feedback is a guidance technique, but there is an art to it that goes beyond the simple presentation of the facts as you see them. To be effective, feedback also needs to be trusted, concrete, and constructive.

 

No matter how upstanding they might be, we do not generally consider people to be objective sources of information in the way that inanimate objects and software tools are.

 

When a piece of code fails a test or doesn’t compile, we do not attribute this to a subjective judgment of the test or the emotional state of the compiler (unless we’re having a really bad day).

 

When we get feedback from people, we are more likely to hear what they are saying through a veil of emotions, cognitive biases, and relationships.

 

It is this question of learning and allowing someone else to do the learning that highlights the weakness of negative feedback. Even without the question of self-esteem, simply pointing out that something is not good is not helpful, and in this case, adding detail doesn’t help.

 

Just saying something is not good does not tell someone what is good. There is little they can learn from it. It’s like a no-entry sign on a one-way street: you are told which way you should not go, but you are not told which way you should go.

 

Negative feedback is often given in response to seeing a problem, but it is not intrinsically problem-solving and constructive. To be constructive, you need to offer a concrete suggestion for improvement or you need to make the giving of feedback part of a problem-solving conversation.

 

If you want someone to learn, create the opportunity and environment for them to discuss and contribute; otherwise, the feedback becomes more about the person giving the feedback than the person receiving it. Feedback should have a purpose and it should enable purpose.

 
 
Team leader Role and Responsibility 8:

Influence Patterns

Influence Patterns

A big part of the frustration I have felt, and that you might be feeling, is about helplessness. You believe in doing the right things, but you just can’t seem to get the people around you to change their behavior.

 

What about using my authority?

Using your authority is usually the path you should take last unless you’re in survival mode. Then, using authority is the second best choice after having people intrinsically motivated to be doing something different.

 

Also, when it comes time for the learning and self-organization phase, telling people what to do is a very ineffective way to teach. Helping them find their own path that makes everyone win is a much more effective way to teach new skills.

 

I know that I and some others think of only the first two forces (personal ability and personal motivation) when we try to understand why a person is not doing anything.

 

Because our profession requires us to think as logically as possible, many times we think that if we only explain a subject or a reason, then that someone will immediately “convert” to our point of view. We are then stumped when that does not happen:

 

“I sent him on a two-day unit-testing course and explained all the benefits of unit testing. He is obviously lazy or doesn’t care about the project.”

 

This is what happens when we run out of options to consider: we start looking at dark crevices in our mind and start putting words in people’s mouths without even asking them. Many times, we play this “I know what he’ll say” game because we are afraid to talk face to face with that person about what truly bothers us.

 

Maybe not entirely consciously, but it’s hard to deny that this happens to many of us. Remember, it is your job to do all the hard stuff, and that includes gently confronting people and talking with them about serious issues. This has to be done in a personal setting (a one-on-one meeting), but it does need to be done.

 

Now that you have the basic list of rules, let’s see how you can use them in real life.

 

A note about privacy: Never discuss private matters with that person or other people publicly. Talk in a one-on-one setting, because it can be very hurtful for people to be confronted or asked a personal question in public.

software team leader

Team Meetings Provide an Opportunity for the Sales Leader to Set the Tone

 

Your sales meeting may be your best opportunity as the leader to set the tone for your team. What you communicate has a huge impact on your sales culture. Your physical appearance, voice inflection, body language, facial expressions, clothing choices, intensity, and, of course, your words, all speak volumes to the team.

 

Is there a “proper” style for a sales manager? I can’t say there is. Do we all need to act like impassioned football coaches or have the leadership ability of Vince Lombardi to create a winning sales culture? No, we don’t. I’ve seen men and women with varying personality styles and approaches do very nice jobs leading their sales teams.

 

But if you allow me to editorialize a bit, I do believe there is something to be gleaned from professional sports coaches, particularly because sports coaches are judged by wins and losses (results) just like sales managers are!

 

What would it look like for you to help your team start winning at your next sales meeting? How might your tone, approach, and expectations have to change?

 

Let me be direct here. As the sales leader, you must be positive and optimistic. It’s your job to point to the sales goal and tell the troops that we are going to hit it; we are going to win! Yes, earlier I did say that various personality types can succeed in sales management roles.

 

Not everyone needs to be a wildly extroverted cheerleader, and in certain businesses, a more reserved person might even be a better fit.

 

But there is one trait that sales managers absolutely cannot have: negativity. If the manager is negative, the team is doomed. As goes the leader, so goes the team. The level of the team rarely, if ever, exceeds the level of the leader. If the leader doesn’t have a winning attitude, there is no way the team will.

 

As you gather your team for meetings, what message are you sending? Everyone is looking to you to set the tone and the pace.

 

Team leader Role and Responsibility 9:

Productive Sales Meetings Align, Equip, and Energize the Team

Sales Meeting

Look over your recent sales meeting agendas. Which regular agenda items have become stale or useless and should be deleted? What potential agenda topics deserve more time and would help you not only alter the dynamic in the meeting, but also foster the kind of winning culture you want to establish?

 

How are you challenging the team, engaging their hearts, and helping each salesperson to see himself as part of something great?

 

Take advantage of this wonderful platform to lead, influence, and equip your team. The sales team meeting shouldn’t be seen as drudgery or something you take for granted and do by rote.

 

Here’s one last idea if you’re serious about ramping up team meetings. Call together a few of your best people and ask them for honest feedback about past sales meetings. Solicit their input for what they’d like to see and ask what would be most valuable to them.

 

I guarantee that you will get very useful information, and your people will appreciate that you sought their input. It’s worth repeating: Sales-people should look forward to team meetings because they benefit from being there and leave more energized and better equipped to win.

 

Team leader Role and Responsibility 10:

Right Direction

Right Direction

I have addressed leading the team, creating a healthy culture, and managing talent, so it’s time to turn attention to the final critical piece of the sales management framework—ensuring that your team has a basic sales process in place.

 

I deploy the simplest of models to help sales teams gain clarity on executing a successful new business development–focused sales effort. The very first step in the model involves selecting what I call targets, which are simply the named existing customers and prospective customers that a salesperson identifies and commits to pursuing new business.

 

This critical step is often overlooked by sales managers, who take for granted that their people have well-thought-out lists and are calling on the right targets. But selecting targets is too important to leave solely up to your salespeople.

 

The harsh truth is that even the most talented people will fail if they’re pursuing the wrong targets, which is something no manager can afford!

 

As the leader, you want to have input into whom your team members are targeting. It is a rare opportunity to be strategic, to set direction. If you are ultimately responsible for leading your team into battle and assume ownership of the ensuing results, shouldn’t you be heavily involved in directing the attack?

 

As hard as this is to grasp, the truth is that many salespeople and sales teams operate day after day without a list of strategic targets.

 

Why? Because they live in reactive mode, responding only to leads or to customers that raise their hands. But the moment we ask them to shift into proactive mode, the natural and necessary first question is “Who should we target?”

 

Since a salesperson’s target list effectively drives how that individual spends proactive selling time, I believe that management should be very much involved in determining which accounts make the list, who should be targeted.

 

Team leader Role and Responsibility 11:

Fix just-in-time errors

errors

Remember to help everyone on the team fix their language, as it happens. The more you do it, the faster everyone will get used to it:

  1. “Would you mind using ‘I will..by’’ instead?” (and smile!)
  2. “So you will..” (and smile)
  3. “Great, you just forgot to use commitment language. Can you try?” (and smile)

 

Don’t smile too much though. That will come off as creepy. I’ve been told.

Don’t worry about feeling like a jerk, but be nice and polite. Leadership can sometimes feel pretty lonely even without being a jerk. Take comfort in knowing you’re driving your team toward better integrity and that it takes a month or two to make a big difference.

 

What if they fail to meet their commitments?

If I set a meeting with you in a place downtown at 9 am, and on the way I realize I won’t make it in time because of a traffic jam, I make sure to notify you as early as possible that I might be late. If I wait until the last minute that’s just bad manners. For a project, waiting until the last minute to say something can be very destructive.

 

What happens when people realize they won’t live up to their commitments, and it has everything to do with integrity. The basic idea is that they raise a red flag as quickly as possible.

 

Ask your team that as soon as someone realizes they will not make their commitment, they raise a flag as quickly as possible to the entire team or to you (if it was a personal commitment).

 

The quicker they raise the flag, the bigger the chances that the team, as a team, can help out and increase the odds of that person’s living up to their commitment.

 

Team leader Role and Responsibility 12:

Daily stand-up meetings

stand-up meetings

As people come up with problems and hindrances in the daily stand-up meeting, challenge them and ask them, “What are you going to about it?” and see where it leads.

 

Help them figure the problem out and don’t solve it for them. Teach them to solve the problem on their own. Most importantly, teach them the thinking that led to the idea of how to solve it.

 

One-on-one meetings

If during one-on-ones, the team member raises an issue, see if you can help them solve it on their own. Help them figure it out, and mentor them to completion. Next, let’s talk about what happens when someone doesn’t live up to their commitments.

 

Don’t punish for lack of trying or lack of success

When people are challenged to solve their own problems, it’s important not to punish people who didn’t solve them. It’s their problem, so they will continue to suffer for it. The consequence is that they will keep having the problem. If they care about it enough, they’ll keep trying.

 

If you’re not giving them the tools to solve it, though, that’s an even bigger problem. You can’t ask them to solve a problem and not support them when they attempt to solve it.

 

Having their back can mean many things. Here are the most important two:

  1. Give them enough time to work on the problem.
  2. Give them permission to approach people they need to without you.

Next, we’ll take a look at a simple concept I used successfully many times, which I call homework.

 

Homework

Homework Tips

Challenging for growth doesn’t just have to be the technique to use when people approach you. You can add a more structured and planned growth trail for team members, by having bi-weekly one-on-one meetings where you can also discuss the idea of homework.

 

Homework is things that a team member could do better or things they need to do better because they hurt the team. It doesn’t have to happen outside of work, but it may not be specifically related to the current work that person is doing (sidewalk might be a less confusing name for some).

 

Things to consider as areas of growth during homework are:

  1. Something they feel will inspire them.
  2. Something that will get them out of their comfort zone (you can tell if they are afraid of doing it).
  3. Something that needs to change because it hurts the team (morale, productivity, teamwork).

 

Things that don’t fit in, but seem like they do, are:

  1. Learning the latest buzzword technology on the same platform (I know technology X but want to learn this framework).
  2. Learning a new platform without learning its culture (I want to learn Ruby, but I won’t assimilate with an experienced Ruby team).

 

You can usually easily tell the difference between a true growth opportunity and a fake one if you know what to look for:

The absence of fear: If the team member is not even a little afraid of taking a step, it’s probably not taking them out of their comfort zone.

 

A good example of a true growth opportunity is switching to a different team or speaking to someone they are afraid to speak with.

• The absence of annoyance/frustration before starting: if the team member is not even a little frustrated or annoyed about how it’s not their job to do X, you might not be truly teaching them something new.

 

A good example of a true growth opportunity is doing work that was never part of their job description or sitting in a room with people they never had to work with. In essence, homework is about learning a new skill, not a new technology. So always ask yourself and your team, what skills are missing?

 

Team leader Role and Responsibility 13:

Homework is a personal commitment, not a task

Homework

During one-on-ones, if someone takes on homework, they should treat it as a personal growth challenge, not as a work task.

 

In other words, they shouldn’t be punished for not doing it because they’re the only ones hurt from it. The desire to get better and break your own limits is what drives this homework, not a manager telling someone what to do.

 

That’s why taking on a personal homework task should be said in commitment language but should be judged only at the personal growth and mentorship level, not at the work level.

 

Homework has follow-up

I consider it homework if I can get an email from a person at the end of each day or each week or have a one-on-one meeting each week about the progress they make. Any longer period of time and we start to lose focus or track of what’s being accomplished.

 

Homework examples

Let’s say one of your team members is a slow typist. In fact, they use the mouse for almost everything. This is hurting your team because people hesitate to pair with them because of how slow things get done.

 

You can sit down with this person and ask them if they knew they could become faster if they wanted to. Most devs would be thrilled at such an idea. You can then suggest ideas or, better, ask them for an idea of how to get better. For example, get a “blind typing” teaching program and measure words per minute over a few weeks.

 

Another example would be someone who’s always negative. You know, the “it’s never going to work” type you’ve had on the team for a while now. The first step is to have a one-on-one with the person and explain that they can benefit much from choosing their battles. Homework here could be >“Say the word ‘no’ no more than three times a day.”

 

Then, you can also ask the team member to email you at the end of each day when they said “yes” or “no” and why. This isn’t about punishment; it’s about being there as a mentor and personal reminder, someone to bounce ideas off and to give advice when needed.

 

Homework and its effects can take months to change behavior or craft new skills, so plan to give it three to six months. Don’t expect results in a week for some things.

 

Remember, one of the reasons you got out of chaos is so that you will have that extra time for people in your team to learn and experiment with new skills.

 

Use that time and let people use it to try these new commitments. It’s important not to overdo it, though, as you’ll see next.

 

Team leader Role and Responsibility 14:

Pace yourself and your team

It’s important not to push this too far. If your answer to every question is “What are you going to do about it?” you’re going to stop getting questions at some point; It’s going to be too quiet, and it won’t quit because people know how to solve their own problems. You’ll see that they can’t but won’t ask for help anymore.

 

That’s how you know you’ve gone too far with challenging them. So, make sure to challenge people on no more than a couple of fronts at the same time. Don’t swamp people with challenges.

 

Give them time to work on one or two challenges at a time and then move on to the next challenge. Now that we are pacing ourselves, let’s talk about when to step in even though people are learning.

 

Do you have enough learning time to make this mistake?

learning time

Sometimes you’ll see people going down the wrong path on a problem and you’ll have to make the decision whether you should let them follow that path and learn for themselves why it’s wrong or keep them away from it completely.

 

That depends on how much time you can spare. If getting out of the hole they are digging will take longer than you’ve made a buffer time for, you might want to take charge and redirect the efforts. 

 

Take, for example, having a team use no source control. If you lose all of your work, it would take too much time to restore. So usually you can’t afford that decision.

 

That’s why even if in the learning phase you should strive to be a mentor, sometimes you’ll have to be a dictator.

 

Are there situations where you should not grow people?

What if you have a short-term consultant on your team? What if you’re the team lead for just this project, and there will be a new team lead on the next project? Should you work on growing people even in those situations? My answer is an unequivocal “yes.”

 

People who come across my path, even for a short time, will get the same amount of respect, expectations, and challenge from me as if they had been there forever. I try to always leave people whom I’ve led better off than they were, in terms of new skills and challenges. It’s my personal integrity to do so.

 

If you conduct yourself this way, you’ll find that people will want to work more with you and will remember you even years later, no matter how short the project was.

 

You never know when you’re going to meet those people again, and you may find hidden treasures are lying in your future path just because a few years back you did the right thing with people who didn’t expect you to. Show a personal example that even in the short term, you don’t give up on quality (of people, of leadership).

 

Team leader Role and Responsibility 15:

BE A TEACHER AND A MENTOR

One of the hardest things to do as a team leader is to watch a more junior-level team member spend three hours working on something you know you can knock out in 20 minutes.

 

Teaching people and giving them a chance to learn on their own can be incredibly difficult at first, but it’s a vital component of effective leadership.

 

This is especially important for new hires who, in addition to learning your team’s technology and code base, are learning your team’s culture and the appropriate level of responsibility to assume.

 

Much like the role of manager, most people don’t apply for the role of men-tor—they usually become one when a team lead is looking for someone to mentor a new team member.

 

It doesn’t take a lot of formal education or preparation to be a mentor; in fact, you primarily need three things: experience with your team’s processes and systems, the ability to explain things to someone else, and the ability to gauge how much help your mentee needs.

 

The last thing is probably the most important—giving your mentee enough information is what you’re supposed to be doing, but if you overexplain things or ramble on endlessly, your mentee will probably tune you out rather than politely tell you she got it.

 

SET CLEAR GOALS

This is one of those patterns that, as obvious as it sounds, is solidly ignored by an enormous number of leaders. If you’re going to get your team moving rapidly in one direction, you need to make sure they all understand and agree on what the direction is. Imagine your product is a big truck (and not a series of tubes).

 

Each team member has in his hand a rope tied to the front of the truck, and as he works on the product, he’ll pull the truck in his own direction.

 

If your intention is to pull the truck (or product) northbound as quickly as possible, you can’t have team members pulling every which way—you want them all pulling the truck north.

 

The easiest way to set a clear goal and get your team pulling the product in the same direction is to create a concise mission statement for the team.

 

Once you’ve helped the team define their direction and goals, you can step back and give them more autonomy, periodically checking in to make sure they’re still on the right track.

 

This not only frees up your time to handle other leadership tasks but it also drastically increases the efficiency of your team.

 

Teams can (and do) succeed without clear goals, but they typically waste a great deal of energy as each team member pulls the product in a slightly different direction. This frustrates you, slows progress for the team, and forces you to use more and more of your own energy to correct the course.

Recommend