PLC Data Protocols

Share / assign

Why it works

Many schools give PLCs time with data and are then disappointed by what happens: the team looks at a report, makes some general observations, offers a few explanations (often ones that locate the problem in students or their circumstances), and leaves without having decided to do anything differently. The data was examined but changed nothing. The missing ingredient is usually a protocol, a structured sequence that disciplines how a team works through data so the conversation reliably reaches a decision. Without a protocol, data meetings default to predictable failure modes: admiring the data (describing it endlessly without acting), explaining it away (rationalizing results rather than responding), drifting to blame (attributing outcomes to students' deficits or home lives, which ends inquiry), or jumping to solutions before understanding the problem. A good data protocol prevents these by separating and sequencing the thinking. A common and effective structure moves through distinct stages. First, predict or prepare, surfacing expectations before seeing the data so the team notices what surprises them. Second, observe, stating only what the data literally shows, factual observations without interpretation, which keeps the team grounded and slows the rush to conclusions. Third, infer, now interpreting what the observations might mean and generating possible explanations, including instructional ones the team can act on rather than only external ones they cannot. Fourth, decide, choosing a specific instructional response, who will do what, for which students, by when. And fifth, plan to revisit, deciding how and when the team will check whether the action worked, which closes the loop. The discipline of the stages is what produces the result: observing before inferring stops premature conclusions; focusing inferences on instruction rather than student deficits keeps the team's attention where it has agency; and requiring a concrete decision with a revisit date ensures the meeting ends in action. The protocol also depersonalizes the work and makes it safe, since everyone follows the same steps and the focus is on collective improvement rather than individual judgment, which is essential when a teacher's own students' results are on the table. The facilitator's job is to hold the protocol, keeping the team in each stage and not letting it skip to blame or solutions. The workshop helps leaders and coaches run a data protocol on a real set of student data, holding the team through observe, infer, and decide so the meeting produces an instructional action.

The research: Research on data teams, protocols, and collaborative inquiry.

The run-of-show

Choose your slot. The agenda, timings, and length update to match.

The core activity: run a data protocol to a decision

The heart of the session is working a real data set through observe, infer, and decide, holding each stage.

Name the failure modes a protocol prevents: admiring the data, explaining it away, drifting to blame, or jumping to solutions.
Observe before inferring: state only what the data literally shows before interpreting, which slows premature conclusions.
Keep inferences instructional: generate explanations the team can act on, not only student-deficit explanations that end inquiry.
Require a concrete decision (who, what, which students, by when) and a plan to revisit, so the meeting ends in action with a closed loop.

Move from looking at data to decidingWithout a protocol, data meetings admire, rationalize, or blame. A staged protocol walks the team from factual observations to instructional inferences to a specific decision, so the meeting produces an action, not a pile of printouts.

Facilitator notes

Observing before inferring is the key discipline; it stops the team rushing to conclusions and blame.
Steer inferences to instruction; deficit explanations about students' home lives end inquiry and point away from the team's agency.
Require a decision with a revisit date; a data meeting that ends without an action and a follow-up has done nothing.

The protocol makes it safeBecause everyone follows the same steps and the focus is collective improvement, a protocol depersonalizes looking at results, which matters when a teacher's own students' data is on the table.

Adapt it

Elementary: use common formative assessment data and keep the decision small and specific.
Secondary: run the protocol within a course team on shared assessments, focused on instructional response.
Any setting: the facilitator holds the stages; do not let the team skip to blame or to solutions.

Participant handout

One page for every teacher. Print it, or save it as a PDF.

K12 Academics · Professional Learning

PLC Data Protocols: observe, infer, decide, revisit

End the meeting with an action: walk the team from factual observations to instructional inferences to a specific decision and a revisit date.

A pure observation of the data (no interpretation):
An instructional inference the team can act on:
The specific decision (who, what, which students, by when):
How and when we revisit to check it worked:
A failure mode I will hold the team away from:

Make it stick

Data protocols pay off when they end in action. Close by setting the follow-up:

Name a check-in: did the decision get implemented and did the team revisit it?
Bring one data meeting the protocol turned into an action.
Keep holding the stages; the drift to blame returns the moment the protocol slips.

Common questions

Why use a protocol instead of just discussing the data?

Because unstructured data discussion reliably defaults to failure modes that produce no action: admiring the numbers without responding, explaining results away, drifting into blaming students and their circumstances, or jumping to a solution before anyone understands the problem. A protocol prevents these by separating and sequencing the thinking, observing the facts before interpreting them, steering interpretations toward instruction the team can control, and requiring a concrete decision with a follow-up. The structure is not bureaucratic fussiness; it is what reliably gets a team from looking at data to deciding what to do differently, which is the entire point of giving a PLC data time. Teams that discuss freely usually mean well and still leave without having changed anything.

Isn't 'observe before infer' an artificial extra step?

It feels artificial precisely because the natural tendency is to leap straight to conclusions, which is the problem it solves. When a team sees a data point and immediately interprets it, the interpretations are often premature, driven by prior assumptions, and quick to land on explanations that locate the problem outside the team's control. Forcing a stage of pure observation, stating only what the data literally shows before anyone interprets, slows that rush, grounds the conversation in what is actually there, and surfaces details that the jump-to-conclusions habit skips over. It is a small discipline that noticeably improves the quality of the inferences that follow, which is why structured data protocols almost universally include it as a distinct step.

How do I keep a data meeting from turning into blaming students?

Steer the inference stage toward instructional explanations and hold the team there as facilitator. When results are disappointing, the easy and comfortable move is to attribute them to students' deficits, home lives, or prior teachers, all of which end inquiry because they point to things the team cannot change. The protocol counters this by asking, during the infer stage, what in the team's own instruction might explain the results and could be adjusted, keeping attention where the team has agency. Naming the blame failure mode openly beforehand helps, as does the protocol's depersonalizing structure, and the facilitator's job is to gently redirect when the conversation drifts toward student deficits, returning it to the question of what the team will do differently.