Greater Than The Sum Of Its Parts: Leading High-Performance Teams

A good leader doesn't tell the team what to do.  They model the behavior that they want from the team, and learn how to encourage people who get on board with it.

So what types of behavior should a leader demonstrate?

Look in the mirror

Every leader wants a high-performing team, but very few do what it takes to actually create one.  Building high-performance teams is hard.  It involves a lot of work, and a lot of risk on the part of the leader.  It is much easier to go along with the status quo, and "manage up" while you aim for the next promotion.
If your team isn't performing the way you want them to, it's your fault.  Accept that and you have a powerful incentive to learn and change.  Even if you have organizational obstacles, even if your boss seems like a short-sighted jerk, you're the leader and you have the responsibility and the power to effect change.

A good team deserves a good leader.  To become one requires a significant investment on your part.  On the upside, becoming one is one of the most rewarding work-related experiences you will ever have.


Do, don't tell

Telling your team what you want or what you think isn't a convincing way to lead.  Your actions speak much louder than your words.  Leading means doing the things that you want your team members to do. 

Failure is safe

"I screwed that up" is a very powerful phrase.  Simply admitting error is good, but admitting you made a mistake and you don't feel bad about it is better.  Failure is a much better teacher than success, and being able to quickly learn and move on is the central characteristic of a high-performing team.

Individuals don't succeed, the team does

For the leader, this means not taking credit for the team's work.  Have different team members run the team's demo.  (Regular demos are central to agile software delivery, but they should be part of any team's regular cadence.)  You should also look for opportunities to praise people's good work in front of your boss or any other stakeholders, but try to frame it in terms of collaborative work.  Don't worry - you'll still look good in front of the boss.  A great team-builder is much more valuable than someone who does great individual work.

Don't solve the team's problems for them.   Whenever an individual comes to you for answers, use that as an opportunity to facilitate collaboration.  Get at least one other team member involved in the conversation.  Encourage them to share ideas.  Act as the secretary to capture their ideas and feed them back.  It doesn't matter if they don't come up with the same approach that you would - they'll be much better at implementing their own idea than they would be implementing yours.

Encourage Experimentation

This goes along with "it is safe to fail."  You want the team to test out new ideas, but not get bogged down if they don't work out.  "What's the simplest thing we can do to see if this will work?" is a powerful question.  "What did we learn?" is another.



These things are powerful whether you're delivering software, building a marketing campaign, or managing corporate finances.  Having a team-oriented, fail-forward mindset is a great benefit whether you call your team "agile" or not.

photo credits

Alex Iby

José Alejandro Cuffia