Team Roles Workshop

Today we stop talking about teams.

You are building one.

Your group gets a fictional scholastic esports program. You have players, computers, a coach, and a competition schedule.

That is it.

No role structure. No practice system. No backup plan. No clear ownership.

Basically, you are being handed the team five minutes before something goes wrong.

Have fun.

Your mission

Create a Team Role Blueprint.

The blueprint should make it possible for a new team member to answer:

• What am I responsible for?
• Who do I support?
• Who supports me?
• What information am I expected to communicate?
• What happens if I cannot perform my responsibility?
• How do we know whether the system is working?

If your blueprint cannot answer those questions, it is not done.

Step 1: Define the team's needs

Do not start by inventing cool titles.

Start with responsibilities.

Ask:

What must happen for this team to function?

Possible needs include:

LIVE COMPETITION

game responsibilities
communication
decision making
time awareness
information sharing

PRACTICE

scheduling
goal tracking
replay review
practice organization

MATCH OPERATIONS

account readiness
equipment checks
reporting results
league communication

Your game may create additional responsibilities.

Need first. Title later.

Bad design:

CAPTAIN
CO-CAPTAIN
STRATEGY OFFICER
TEAM LEADER

Fine. What do they do?

Nobody knows.

Better:

NEED:
Someone must make the final time-sensitive tactical decision.

RESPONSIBILITY:
Gather teammate information and make one final call.

OWNER:
Player 2

ROLE TITLE:
Tactical Caller

Now the title means something.

Step 2: Build role cards

Every role needs:

ROLE NAME

OWNS

SUPPORTS

COMMUNICATES

BACKUP

EVIDENCE

Example

Role: Practice Coordinator

Owns: making sure the practice schedule and weekly focus are posted.

Supports: coach and team captain.

Communicates: practice time, focus, and required preparation.

Backup: team captain.

Evidence: every team member knows the practice time and focus before practice begins.

Notice that the evidence is not "they are good at their job." We can actually inspect it.

Step 3: Add support

No important role should exist as an island.

Draw connections.

TACTICAL CALLER
      ↑
information
      |
PLAYERS
      |
      ↓
final decision

Another:

PRACTICE COORDINATOR
       ↓
schedule
       ↓
PLAYERS

       ↑
       |
     COACH
   practice goal

The arrows matter. They show dependency.

Step 4: Add backup

Now I am going to remove somebody from your team.

Not permanently. They are absent.

What happens?

If one absence causes the entire team system to collapse, your design is fragile.

For every critical role, identify:

Who takes over?

This is redundancy. Redundancy is not only a computer-systems concept. Teams need it too.

Step 5: Add evidence

How do you know the role is working?

Weak evidence:

Good leadership.

What does that mean?

Better evidence:

Players receive the final tactical call from one agreed person during time-sensitive decisions.

Now you can observe it.

Weak evidence:

Good communication.

Better evidence:

Critical information is called before the team commits to the next action.

Observable.

Blueprint requirements

Your group must design at least five roles.

Each role must contain one clearly owned responsibility, at least one supported responsibility, one communication expectation, a backup person, and one piece of observable evidence.

Your complete blueprint must also contain at least 8 role connections, at least 2 shared responsibilities, at least 3 backup relationships, one practice goal, and one method for reviewing accountability.

Stress Test 1: Captain absent

Your captain cannot attend. What breaks? Who takes over? What does not change?

If everything collapses, fix the design.

Stress Test 2: Two people make the call

During a close match, two players give contradictory tactical instructions. Which role owns the decision? What should everyone else do?

If your blueprint does not answer this, fix it.

Stress Test 3: Someone stops communicating

One player performs their mechanical role well but stops giving information.

Are they still fully performing their role?

Maybe not. A responsibility can include communication.

Stress Test 4: Practice is not working

The team has practiced for two weeks. Nobody can explain what improved.

What is missing?

Probably evidence. Add it.

Stress Test 5: The best-player problem

Your strongest individual player argues:

"I should make every important decision because I am the best player."

Could that work? Maybe.

But analyze the risk. What happens to teammate information, role ownership, leadership development, cognitive load, trust, and backup capacity?

Do not assume skill in one area means skill in every area.

Stress Test 6: Nobody did it

A tournament result was supposed to be submitted. It was not.

Three teammates say:

"I thought somebody else had it."

Classic.

Which blueprint field failed?

Ownership.

Fix it.

Team defense

Your instructor will choose one role. You have 60 seconds to defend why the role exists, what it owns, who depends on it, who backs it up, and what evidence proves it is working.

If your group cannot answer all five, the role needs work.

Final artifact

Create your Team Role Blueprint in Google Slides or another instructor-approved format.

Suggested layout:

SLIDE 1
Team + game + purpose

SLIDE 2
Team responsibility map

SLIDES 3-7+
Individual role cards

NEXT SLIDE
Backup / redundancy map

NEXT SLIDE
Practice goal + accountability evidence

FINAL SLIDE
Stress-test results

Make the arrows mean something. Do not turn this into decorative boxes floating around a slide. We are mapping the actual team.

Before you leave

Look at your blueprint. Find the role people would probably notice least when everything is working.

Now imagine that role disappears.

What breaks?

Write the answer down. You will need it for your reflection.

Source note

This workshop synthesizes Learn with League's instruction around team roles, player obligations, communication, cooperation, practice, and responsibility.

Robotnix Academy extends those ideas into an original team-design exercise using role ownership, support, backup coverage, observable evidence, dependency mapping, and failure testing.