Team Coordination Toolkit

Most student projects do not fail on the engineering. They fail because nobody could say who owned a piece of work, because someone sat stuck for two days without asking, or because the team spent forty hours in meetings about thirty hours of work. Three small instruments for those three failures.

How to use this tool
  1. Part 1 — the RACI grid. Add your team, add the tasks, then set one role per person per task. The grid checks itself as you go: every task needs exactly one A and at least one R.
  2. Part 2 — the blocker message. Fill in the five fields and the tool assembles a message you can paste into Slack, Teams or an email. The fields are the ones your reader needs and no others.
  3. Part 3 — the meeting cost. Put in the head count, the length and a rate. The number is not an accounting figure. It exists so you can hold it next to the work the meeting is about.
  4. The analysis near the bottom reads all three parts together, because coordination problems rarely stay in one place.

The point of the RACI grid is not the grid. It is the argument you have while filling it in. If two people reach for the same A, you have found a real disagreement about ownership that would otherwise have surfaced in week eleven.

Every control is a button, a select or a text field. Nothing requires dragging or a mouse.

How this maps to Jira and similar trackers
HereJiraAsana / Trello / Linear
R — ResponsibleAssigneeAssignee / Owner
A — AccountableReporter, or the epic ownerProject owner / Task creator
C — ConsultedRequested reviewer, or an @mention on the ticketCollaborator
I — InformedWatcherFollower / Subscriber
Blocker messageStatus "Blocked" plus an "is blocked by" link and a commentBlocked-by dependency plus a comment
Needed byDue date on the blocking issueDue date

Assignee, reporter, watcher. The assignee is the one person whose name is on the work — Jira allows exactly one, which is not a limitation, it is the whole idea. The reporter is whoever raised the issue and usually the person who decides whether it is actually done; on a well-run board that is your A. Watchers get every update and owe you nothing; that is your I. Adding someone as a watcher is cheap, so people over-add, and then nobody reads the notifications. Being deliberate about who is C and who is I is the difference between a ticket people follow and a ticket people mute.

Blockers. A blocked ticket usually gets two things: a link ("is blocked by ENG-412") and a comment saying what is needed and from whom. The link is what shows up in reports; the comment is what a human actually reads. Escalation is normally time-based and boring — you raise it in standup, then you tag the person directly, then you ask your lead to help unstick it. Teams differ on how long each rung lasts. What almost every team agrees on is that a blocker nobody mentioned is worse than a blocker mentioned too early.

Standups. The ritual exists so blockers surface within a day of appearing. It goes wrong in predictable ways: it turns into a status report to the lead rather than a coordination between peers; it drifts into problem-solving that only two of the six people need; or it becomes a place to perform busyness, where "I'll keep working on it" is said three days running and nobody asks what changed. The fix is unglamorous — say what is blocking you, name the person who can unblock it, and take the debugging to a separate conversation.

An honest note on RACI. Formal RACI charts are far more common in large organisations, consultancies and regulated projects than in five-person engineering teams. Plenty of working engineers have never filled one in. But the questions the grid asks — who is doing this, who answers for it, who gets a say, who just needs to know — get answered on every team whether or not anyone writes them down. On small teams they get answered informally, and often badly: by whoever speaks first, or by whoever cares most, or by default when the deadline arrives and it turns out nobody did the thing. Filling in the grid once, early, is a cheap way to have the argument while it is still cheap.

Part 1 — Who owns what (RACI)

  • R Responsible — does the work. Can be more than one person, but somebody's hands are on it.
  • A Accountable — the single person answerable for the outcome. Exactly one per task.
  • C Consulted — gives input before the work is done. Two-way.
  • I Informed — told after. One-way. Costs them nothing.
Team members
Tasks

Part 2 — Asking for help without wasting anyone's time

The norm on most engineering teams is to ask after a bounded amount of time stuck — often somewhere around 30 to 60 minutes of genuinely being stuck, not 30 minutes of having the file open. Both directions are real failure modes with different costs. Ask too early and you spend someone else's attention on something you would have solved in ten more minutes, and you learn less. Ask too late and you burn a day of your own time on something they would have answered in ninety seconds, and the schedule eats it. The second mistake is more expensive and much more common.

Build the message

Without this, the first reply you get is "have you tried the obvious thing," and you have lost another hour.

The assembled message

Part 3 — What this meeting costs

The meeting

The default rate is a rough loaded cost for a junior engineer's time. Argue with it if you like — the point is the comparison, not the precision. A number that is wrong by 30% still tells you whether a recurring meeting is cheap or ruinous.

What the meeting costs, once and across the term
MeasurePer meetingWeekly, across the term
Meetings1—
Person-hours——
Cost——

Fill in the numbers above and the comparison appears here.

Conditions under which the meeting is probably the right call anyway

If none of these are true, what you have is a status update, and a written one costs the team the two minutes it takes to read rather than the whole person-hours figure above. Written also leaves a record, lets people read it when they are not mid-task, and does not require six calendars to agree.

Add a person and a task to start, or load the example.

What the three parts say together

Fill in some of the toolkit and observations will appear here.

One more question

Keep your work

This tool remembers your work in this browser on this device. Nothing is sent anywhere.

Autosave is on.