Roles: sponsor, lead, expert, one owner per task

Most confusion in a project is about roles, not tasks. Four roles answer four different questions.

• The sponsor answers for why the project exists: the goal, the money, the fixed date, and any change to them. At Klasna that is Leo.
• The lead answers for how it gets done: the plan, the buffer, the weekly status, and bringing decisions to the sponsor. That is you.
• The expert answers for a quality only they can judge: Vira, for the program and the tutor standard.
• A task owner answers for one piece of work being finished, even when others help.

When these blur, the symptoms are familiar. Everyone asks the expert about everything, as Vira found when marketing, Danylo and Leo all came to her in one day. Or the lead quietly makes the sponsor's calls, and nobody knows whether a decision really stands.

In a small team roles and people don't map one to one. Vira writes the curriculum and scores the demo lessons (a task owner), sets the standard for tutors (the expert), and is asked about the program claims on the landing page (consulted). Danylo owns the test, the landing page build and booking by subject, but is only consulted on the landing page text.

That isn't a problem to fix by hiring. It works as long as each hat is explicit: for every task, which role this person is playing. Trouble starts when the hats blur, so a request to "approve" lands on Vira for things she only needs to be consulted on, or Danylo is treated as the owner of words he only puts on the page.

A simple habit helps: when you ask someone for something, say which role you are asking them in.

A light responsibility table lists each task, its owner and who is consulted. It is useful only if every row passes one test: exactly one name in the owner column.

Three kinds of row fail. Two owners ("the marketing lead and Danylo" for the landing page text) usually means none: each assumes the other is on it. "The team" as owner (tutor contracts) is the same problem at a larger scale. An empty cell (the waiting list review) means nobody at all, and it will surface only when the date is missed.

Rows with one name and the right person consulted are fine, even if a detail looks odd. Klasna's diagnostic test (Danylo owns, Vira consulted) and the outside review (Vira owns) pass. Consulting Leo on the review is unusual but harmless: the test is about ownership, not style.

When a task stalls with two owners, the fix is not more cooperation; it is one name. At Klasna the landing page text hadn't moved for a week because marketing and Danylo both "owned" it.

Split the roles around the task instead. The owner answers for it being finished: the marketing lead, since the words are marketing's. Others do parts of the work: Danylo builds the page. Others are consulted: Vira checks the claims about the program before publishing.

Two tempting fixes make it worse. The lead taking the task over confuses answering for the plan with doing every task, and leaves the lead's own work undone. Escalating to Leo to write the copy pulls the sponsor into work that isn't his. Asking both to "work together and report jointly" keeps exactly the shared ownership that caused the stall.

Besides the owner, a responsibility table names who is consulted: people whose view is asked before the decision, because they know something the owner needs. It is a real role with a real limit. Being consulted means your input is heard and weighed; it doesn't mean you can block the decision or take the task over.

At Klasna the marketing lead owns the waiting list review on 20 December and brings the numbers. Danylo is consulted: if he thinks the numbers are presented badly, he says so before the review, and the owner decides what to change. Afterwards he uses the numbers for the go or adjust call on his part of the plan.

Keep the consulted column short. Every name there is someone the owner must wait for, so add people only where their view really changes the result.

Roles matter most when they pull in opposite directions. Only six candidates have passed Vira's demo lesson; Leo wants to count two who nearly passed to reach eight. Vira refuses: "nearly passed" meant explaining Newton's laws wrongly to a fourteen-year-old.

The brief made eight tutors who passed a demo lesson a success criterion. Changing a criterion of the signed brief is a sponsor decision, made in writing (Leo agreed to decide changes within two working days), and only after hearing the expert, who owns the quality bar. The lead brings the options and their cost: a second round of demo lessons from the contingency reserve, or opening with six tutors and fewer learners.

What must not happen: the bar quietly lowered, the expert overruled in a corridor, or a verbal "fine, count them" in a meeting that leaves nobody sure what was decided.

When a success criterion collides with reality, the order of steps keeps the decision clean.

1. The expert states the bar and why. Vira explains what the two candidates got wrong. Without this, the sponsor decides about a number, not about lessons for real learners.
2. The lead lays out the options with their cost and effect on the date: a second round of demo lessons, paid from the contingency reserve, or opening with six tutors and fewer learners.
3. The sponsor decides in writing, within the two working days agreed in the brief.
4. The lead records the decision and updates the plan, so everyone works from the same version.

Until step 3 the brief's criterion stands. The lead doesn't decide; the expert doesn't veto the business choice; the sponsor doesn't decide blind.

A responsibility table earns its place only if people read it and it answers a question quickly: who answers for this, and who must be asked first? Two habits keep it that way.

First, exactly one owner per row, with helpers named only where they do part of the work. Second, consulted only where it changes the result. Listing Vira on all 17 tasks "to be safe" sounds careful, but every owner now waits for her, she becomes the bottleneck the module started with, and the table no longer shows where her judgment really matters: the program, the claims about it and the tutor bar.

Danylo's rule is a good test: a table nobody reads is worse than none.

How it fits together: clear roles, one owner per task and a sponsor who decides changes in writing make the inside of the project work. The next lesson looks outside the table: who can stop or help the project, and how to move them without any authority over them.