Teams and Communication

From a gap in the plan to a communication protocol

In the practice scenario, a check of the plan after game 1 found one clear gap. (In this class, the Week 9 evidence audit has been postponed, so read this finding as a fact of the scenario.) The Week 8 organization chart said that the performer liaison sends messages to the performer. Around game 1, most messages went through Mina, and twice Judy messaged the performer directly. The chart described one path, and the messages took another.

This is common in a small, founder-led company. The founder remembers the context, so a request arrives, a decision is made and the performer hears about it within minutes. It feels efficient, but it is fragile. Nobody else knows which decision was made, what was missing, or who may change it. And a person who sees a problem may stay silent, because the conversation is personal and the founder influences future work.

The practice scenario, which is invented for learning, continues with the 12-week test of Option A · Expansion (expand cheerleading and sports-entertainment talent management). This week it follows one small change through the whole company. In test week 7, the home team asks to move game 2, planned for the Saturday of test week 8, by one day to Sunday, because the arena has a conflict. It is an ordinary request. Handling it well means the right people learn about it in the right language, and Judy's staff keep a clear record of what was decided.

This week's question is: how can a small team replace informal coordination with a system that still works when the founder is busy? The answer this chapter builds is a communication protocol: a short set of written rules that says who needs what information, who decides, and how mistakes are corrected. Its core is a meeting decision log, a running record of decisions and their current status.

Where this week fits

A check of the plan after game 1 found a gap between the organization chart and the way messages actually moved. Week 10 turns that finding into a communication protocol, including a meeting decision log. Week 11 uses the protocol to mark the handoffs in a service blueprint, the points where work passes from one person to another.

The organization chart and the real message path

It is easy to treat communication as a soft skill that surrounds the real work. In a team spread across roles and languages, communication is part of the work itself. A schedule has to reach the performer accurately. A promise to the home team has to be understood by the people who deliver it. A concern has to reach someone who can act on it.

Joseph and Gaba (2020) reviewed research on how organization structure shapes the way information is handled and decisions are made. Their main lesson is that structure should fit where information sits and how fast it must be used. An organization chart shows who reports to whom. The actual message path is a different thing: who tells whom, in which language, and how quickly. The table compares the two in the practice scenario.

Nobody in this table acted badly. Each person took the fastest path they knew. The problem is that fast paths skip the roles designed to check things, such as the performer's 12-hour rest rule and the accuracy of the translation. A communication protocol keeps the chart and adds what the chart leaves out: the route each type of message should actually take.

Shared understanding: what we are doing and who knows what

Teams do not need identical opinions, but they need enough shared understanding to coordinate. Kozlowski and Ilgen (2006) reviewed research on work teams and described two useful ideas. A shared mental model is the team's common understanding of the task, the roles and the situation. It answers questions such as "what are we delivering?" and "which role decides?"

The second idea, transactive memory, is the team's knowledge of who knows what. Week 8 made this point when it designed the chart around who knows and who decides, so that people know who to ask. This week adds only one step: the protocol writes those answers down for each type of message.

Founder-led teams often keep the whole picture in one person's head. Judy may know why the home team matters, or that the performer needs a quiet morning before a game. That memory is fast, but it does not transfer. A new staff member cannot tell which details are essential and which are out of date. So the management task is to decide which knowledge must become shared, and to write it where others can find it.

Shared understanding is different from agreement. A team can understand that a decision is risky and still disagree about going ahead. It can also agree quickly because nobody has seen the missing information. That is why the decision log records a status as well as a result.

Working at the team's edge

Boundary spanning is the work of connecting a team with people outside it: collecting information, representing the team and obtaining resources. Ancona and Caldwell (1992) found that the kinds of outside contact a team kept were linked to how well it performed. So the founder should not be the only person who talks to partners.

Different boundary tasks carry different risks. A person who gathers information may have no authority to commit the company. In the practice scenario, the home team's staff contact talks to Mina about game logistics and to Judy about the agreement. That works as long as each side knows what the other may promise. So assign boundary roles explicitly: what each person may promise, what they must record and what they must pass up to Judy.

Distance: place, time and who bridges

Working across borders is not one single condition. O'Leary and Cummings (2007) described geographic dispersion in distributed teams along three dimensions. Spatial dispersion is how far apart members are. Temporal dispersion is how little their working hours overlap. Configurational dispersion is how members are arranged across sites, for example several people at one site and one person alone at another.

In the practice scenario, the arrangement is uneven. The performer usually lives in Korea, while Judy's staff and the home team are in Taiwan. Mina sits where these groups connect, so she carries an unusual share of the coordination.

Distance costs time. Cummings, Espinosa and Pickering (2009) studied projects in one multinational company and found that working across locations and time zones was linked to coordination delays. Hinds and Mortensen (2005) found that distributed teams had less conflict when members shared an identity and a context and could talk informally. For a small team, the practical lesson is to decide which tasks need everyone at once and which can be done in writing at different times.

Communication in writing at different times is called asynchronous communication. It needs more care than a live conversation. Compare two messages Mina might send about game 2:

• Vague: "They want to move game 2. Any thoughts?"
• Precise: "The home team asks to move game 2 from Saturday to Sunday. Decision needed: does Sunday still give you your 12 hours of rest? Please reply yes, no, or yes with a condition by Wednesday 18:00. If I have no reply, I will call you on Thursday morning."

The first message may produce a long silence, because the reader cannot tell whether an opinion, an approval or a decision is being asked for. The second names the choice, the deadline and what happens if nobody replies.

Language and common ground

Week 4 showed that language decides who can agree and who can object. This week adds a team-level point. Vigier and Spencer-Oatey (2018) observed multicultural project teams and showed how differences in language fluency shaped the rules those teams formed. Guzman and Reiche (2024) found that team members who were more fluent in the working language tended to gain more informal influence. A common language helps coordination, but it can also give more voice to the people who speak it best.

Common ground is the knowledge that people believe they share and can use to coordinate. It is built through repeated work: agree what a word means in this project, show an example, and record what is still unclear.

The word "confirmed" is a good example. For one person, "confirmed" means that the client expressed interest. For another, it means a signed agreement and payment received. A company should agree which meaning it uses, or avoid the word.

When staff work in more than one language, separate translation from confirmation. First, give each reader the message in the language they read best. Second, ask them to say back, in their own words, what they must do and by when. This is a say-back check. It treats nobody as less capable; it recognizes that a translation can be correct in grammar and still unclear about what it asks someone to do.

Who proposes, who decides, who must be told

Many communication failures are really decision-rights failures. Week 2 introduced decision rights, the authority to decide a stated kind of question. A company can exchange messages quickly and still fail because nobody knows who may approve a date change or stop an unsafe plan. Adding another chat group does not fix unclear authority. It often hides the problem, because more people seem to be involved.

For each type of decision, name four roles. The examples come from the game 2 request.

• Proposer: the person who raises the request. The home team's staff contact proposes the move, and Mina brings it into the log.
• Decision owner: the one person who makes the call. Moving a game date changes the agreement, so Judy decides.
• Consulted: the people who must be asked before the decision, because their knowledge or work is affected. Here: the performer about her 12-hour rest rule, the translator about availability, and the bookkeeper about the travel booking.
• Informed: the people who must receive the result and know where the record is. Here, every role on the chart.

In a small team, one person may hold more than one role, but the combination should be written down. The map also protects the founder. Judy's approval is needed for choices that affect the agreement, the brand or a major commitment. It is not needed for rehearsal times, which Mina may change within the agreed dates. If every issue goes up to the founder, the founder becomes a bottleneck, and staff learn that taking initiative is unsafe.

So set thresholds by the kind of risk, not by the amount of money. A change that costs nothing can still raise a consent or safety question. A public statement may need review because it is hard to take back. A workable rule has three levels: decisions made locally, decisions that need consultation, and decisions that need founder approval.

A common tool: the RACI matrix

Many companies write these roles down in a RACI matrix (some teams write it as ARCI). The rows list the tasks or decisions in one piece of work, and the columns list the people involved. Each cell holds one letter or is left blank.

• R · Responsible: the person or people who do the work. A task can have more than one R.
• A · Accountable: the one person who answers for the result and approves it. Each task has exactly one A.
• C · Consulted: the people who must be asked before the work is done or the decision is made. This is two-way communication.
• I · Informed: the people who must be told the result. This is one-way communication.

RACI connects two ideas from this course. The difference between R and A is the Week 2 difference between task responsibility and accountability: Mina may do the work while Judy answers for the result. And A, C and I match the decision owner, the consulted and the informed above. RACI has no letter for the proposer; the person who brings a request into the company, here Mina, is often the R who prepares it. When one person both does the work and answers for it, the cell shows A/R.

The matrix below covers the game 2 request from the worked example later in this chapter. Read it row by row: who does each task, who answers for it, who must be asked and who must be told.

Blank cells mean the person has no role in that task. The performer is marked I in the say-back row because she receives the final plan; the say-back check itself is how the liaison makes sure she understood it. The matrix is also a diagnostic tool. Read down each column: if Judy is A on almost every row, the company is still centralized, and Judy is the bottleneck when she is away. Read along each row: a task with no R will not get done, and a task with two A's leaves people unsure who decides. Many C's slow a decision down; a missing C, such as the performer on a question about her rest, means someone affected was told afterwards instead of being asked first. Put people outside the company, such as the home team's contact, into the matrix as well, because many failures happen at the company's edge. In the matrix above, Judy is A on three of the eight rows. Which of them could Mina own as her decision rights grow?

Three mistakes are common. People mix up R and A, so the person doing the work is blamed for a decision they could not make. People treat C as I, telling someone the result when that person should have been asked first. And teams draw the matrix once and never update it after the work changes.

Voice needs a response

Week 8 taught psychological safety, the shared belief that it is safe to raise a concern or admit a mistake, and Edmondson (1999) linked it to learning behavior in teams. This week adds the communication side. A team becomes safe through what happens after someone speaks. Does the person get a serious answer? Is the person protected from losing future work?

In a founder-led team, the stakes are personal. Judy may have created opportunities for the performer and the translator, and she may also influence their next jobs. A person who stays silent may be making a reasonable judgment about risk. So a protocol needs more than an invitation to "talk to me any time". It needs three routes.

• Everyday suggestions go to the weekly meeting or to a shared list of improvements.
• Sensitive concerns, for example about pay, safety or rest, go to a named person through a private route with a known response time.
• Concerns about the founder, or cases where Judy has a conflict of interest, go to a different reviewer.

The response is part of the system. A short concern record notes the concern, the reviewer and the follow-up date. It must never become a list of "difficult" people.

A quiet meeting also needs care. Silence may reflect respect, uncertainty or a sensible choice to raise an issue privately. Sharing the agenda early and allowing written questions gives more people a real chance to contribute.

Meetings and messages: choose the channel for the job

A meeting should have one clear job, such as sharing information, making a decision or reviewing what was learned. Mixing these jobs without a structure lets the loudest or most senior person decide the outcome. Before calling a meeting, ask what can only be done together.

For a decision meeting, send a short agenda first with the decision needed, the options and who is affected. During the meeting, separate facts from interpretations, and record disagreement instead of forcing agreement. Close by stating the decision's status, its owner and the review date. The record should also show what was not decided.

Many decisions can be made in writing instead. State how long people have to respond. Silence should never count as agreement when the issue affects safety, pay or rights.

Finally, protect attention. If urgent and routine messages share one channel, people learn to check everything constantly, and real emergencies get lost. A small set of message labels helps, as long as everyone agrees on response times.

The meeting decision log

Some people see written records as a sign of distrust. In a company that works across roles and languages, a record is often a form of respect. It spares people from remembering a private promise and protects someone who was not present. It also lets a later manager see why a choice was made, and that makes correction possible.

A meeting decision log is different from a message archive. An archive answers "what was said in this chat?" and may contain several proposals that contradict each other. A decision log answers "what is the current decision, who owns it, what supports it, and when will we look at it again?" When people work at different times, only the log gives a quick answer.

Every entry in the log carries one status from a fixed list. The course uses these five statuses from now on.

A status tells everyone how far they may act. "Proposed" means nobody books travel yet. "Approved" means they may. The log avoids the word "confirmed" on purpose, because people read it in different ways.

Two more habits keep the log useful. A working record, such as the game 2 entry, supports a live decision and needs an owner and a review date. A reference record holds a rule the company reuses, such as how consent is confirmed. And keep only what the work requires. A log exists for coordination, not for watching people, so sensitive details go only to those who need them.

Worked example: game 2 moves by one day

This example follows the request through the protocol.

Monday: the request arrives. The home team's staff contact emails Mina: because of an arena conflict, could game 2 move from Saturday to Sunday? Under the new protocol, Mina does not reply "no problem". She opens a log entry with the status proposed and sends one message marked "decision needed" to Judy's staff and the translator. The translator checks the Korean version, and the performer liaison sends it to the performer.

The message: "Decision needed by Wednesday 18:00. The home team asks to move game 2 from Saturday to Sunday. The call time would stay at 16:00. Performer: does Sunday still leave you 12 hours of rest before your Monday commitment? Translator: are you free on Sunday? Bookkeeper: what would it cost to change the travel booking? Judy will decide once we have your answers. Please do not share this outside the company yet."

Tuesday: the answers. The translator is free. The bookkeeper reports that the airline and the hotel will move the booking free of charge, so travel stays at NT$11,000. The performer liaison asks the performer in Korean, and she says Sunday is fine if the call time is no earlier than 16:00. Judy records the status conditional: Sunday, provided the call time stays at 16:00.

Wednesday: the decision. The home team confirms the 16:00 call time in writing. Judy changes the status to approved, and the liaison sends the performer the updated schedule in Korean.

Here is the log entry, in five lines.

Thursday: the correction. The liaison runs a say-back check. The performer says, "Sunday, arrive at 15:00." The Korean schedule contained a typing error: 15:00 instead of 16:00. The liaison sends a corrected Korean schedule, and the performer says back 16:00.

Mina then adds a line to the log instead of deleting the old one: "Correction (Thursday): the Korean schedule showed 15:00 in error; corrected to 16:00; the performer said back 16:00; found by the say-back check." A visible correction shows everyone where the process can fail. Here, the say-back check caught the error before game day.

Compare this with game 1. Then, the performer heard about a change from Judy in a private chat, and Mina learned about it later. Now the proposer, the decision owner, the people consulted and the people informed are all visible, and the record shows each step.

Where AI fits in team communication

AI tools can translate a message, transcribe a meeting or draft a summary for the log. The specific risk for team communication is that a draft looks like a record. A transcript may leave out a speaker, and a summary may make a disputed point sound settled. So label AI output as a draft until a named person has checked the names, numbers and dates, and never let a summary be the only record when someone's pay, schedule or safety is affected.

The three options need different communication

The same protocol questions apply to all three options, but the main risk sits in a different place.

• Option A · Expansion. More performers and teams mean more handoffs, and each handoff can change a promise. The protocol needs a short brief for each event, one consent and safety rule for all events, and a reliable way to update home teams and performers.
• Option B · Boutique (a small cross-border talent and advisory service for a few clients). Fewer relationships make each one more important. The protocol needs written scope limits, a private route for concerns and a backup for each key relationship.
• Option C · Content-centered return (return to content, advertising, food service and personal brand). A public post can create a customer expectation before anyone has agreed to deliver it. The protocol needs a rule that separates promotion from confirmation.

The table shows common communication problems, the design question each one raises, and the minimum record it needs.

Across all three options, the test is the same. Could another manager understand the current promise, who decides and when it will be reviewed, without asking the founder?

A protocol another person can use

A protocol that can grow with the company rests on a few stable rules. In the practice scenario, the company's protocol has six.

1. Every important request states the decision needed and the deadline.
2. Every decision has one owner, a status from the fixed list and a route for passing it up.
3. Anything that affects safety, consent or pay goes into the log, with what is still uncertain.
4. Messages to the performer are sent in Korean: the translator checks the Korean wording, and the performer liaison, who reports to Judy, sends it with a say-back check.
5. Anyone can ask for a correction, and corrections are added to the log, never erased.
6. Sensitive information is shared only with the people who need it.

Leave room for local adaptation. The written consent rule stays the same everywhere, while the explanation and the language may change. Record what stays common, what was adapted and why. Otherwise local knowledge disappears, or a local exception quietly weakens a safeguard.

Class practice: a communication protocol and one log entry

This practice is done without AI tools. Your teacher will tell you which worksheet to use and how to submit it. Bring your notes from the Week 9 practice on organization design and delegation.

1. Choose one message path. Pick one kind of message in your option, such as a schedule change, a client's extra request or a concern about pay. Write who sends it today and who should send it.
2. Name the four roles. For that decision, write the proposer, the decision owner, who must be consulted and who must be informed.
3. Write the message. Draft one "decision needed" message with the choice, the deadline and what happens if nobody replies. Note which language each reader needs.
4. Write the log entry. Give the decision, its status from the fixed list, the conditions and the next review. Add one correction line for a mistake that could realistically happen.

Label any detail you invent. Keep your protocol for Week 11.

Key points and what you bring to Week 11

• An organization chart shows who reports to whom. A communication protocol adds the route each type of message actually takes, in which language, and who decides.
• People coordinate through a shared picture of the task and a clear sense of who knows what. Write down the knowledge that should not live only in the founder's head.
• For each decision, name the proposer, the decision owner, who is consulted and who is informed. Set thresholds by the kind of risk. A RACI matrix writes these roles down for every task in a piece of work, with exactly one A per task.
• Voice needs a response: a private route, a named reviewer and protection from losing future work.
• The meeting decision log records the current decision and one status: proposed, approved, conditional, disputed or closed. Corrections are added, not erased.

For Week 11. Bring your communication protocol and your log entry. Week 11 draws a service blueprint of a game-day appearance and marks every handoff, each point where information or work passes from one person to another. The message routes you wrote this week become those handoffs.