How well do you know your team?

[#1]

I’ve been thinking a lot about “teams” lately. When someone asks what team I’m on, it gets a little tricky.

Is a team a collection of people who report to the same manager, people who do the same craft, people who work on a project together? Team definitely doesn’t seem like a one-size-fits-all noun.

Sometimes, my team is a set of specialists who are brought together to solve a particular problem by a set date. Other times, my team is a specific set of people who work together on work with a particular focus. It’s kind of like being the cast/crew for a movie versus being the cast/crew for a TV series.

Regardless of which kind of team we mean, it’s always a good idea to get to know who people are, what their strengths are, and how they work best. Teams that take time to build and maintain healthy practices have greater team satisfaction, better team outcomes, and improved performance.

Atlassian created a Team Playbook whose plays range from getting to know one another to decision-making frameworks and retrospectives. It’s up to the team to decide what they need to get things up and running, but there are a few key activities that I’ve found useful.

• Figure out who is on the team and the amount of time they are dedicated to it. You might have some people who are only on the team part of the time.

• Before you meet next, have everyone complete their own user manual. When you meet, take time to have people talk through their manuals. You’ll often get more interesting commentary from the person that they didn’t put on the page.

• Talk about your roles and responsibilities using this play. You’ll also uncover those things that other people think you should be doing and vice versa. Illuminating those assumptions and gaps is key to making sure no one drops the ball thinking that someone else has it.

• Dig into the work. This bit is trickier as it depends on what you know and where you are in the process.

  • If you know the problem you are trying to solve but don’t know much else, start with the Problem framing play.

  • If you understand the problem and need to start getting specific about the team’s purpose, timelines, and what it’ll take to be successful, use the Project Poster play.

  • If you know the problem, have some solutions, and have the details ironed out, then jump into the Project Kickoff play.

Team maintenance and health

The minute you go through any of these activities and plays, they potentially become obsolete because people come and go and projects change over time. This is where it’s good to identify someone in your roles and responsibilities who will get new teammates to create a user manual and someone to review the roles and responsibilities to see if things changed with the addition or subtraction of certain people or crafts.

You may find that your team changes enough to warrant revisiting a play or two. It definitely doesn’t hurt to do this, even if you find that not much has changed. Making people feel a part of the team and its ways of working are really important. People who feel included and empowered are more likely to play as a team.

Please share how you make everyone feel like part of the team?

[Peter Van de Voorde]

I love the structure you've put here in regards to which plays to use when.

Thanks for sharing @Traci Wilbanks 

[Preetha Roseline]

This sounds very interesting. I would love to try it with my team although its hard to make each of them feel comfortable.  
Still Thanks for sharing @Traci Wilbanks