Structuring a small team

Team structure is how work and responsibility are split inside a team. A small support team has three basic shapes:

• By subject: each person owns topics, such as payments or video. Deep know-how, but a vacation leaves a topic uncovered and the knowledge sits in one head.
• By channel: chat people and email people. Simple, but lopsided when most tickets come by chat, and one family's problem gets split between two people.
• A shared pool: everyone takes the next ticket. Flexible, but with no named roles nobody owns the problems that keep coming back, and quality varies.

No shape is best in general; each fails in its own typical way. Judge a structure by two tests: few, clear hand-offs, and a piece of work each person can own. A useful rule of thumb: put the work that needs the closest coordination in the same hands, so it doesn't have to cross a boundary at all.

Every owned area needs a backup, and a backup only counts if they have actually done the work. A name in the team's structure table isn't cover. When the owner leaves for two weeks, a backup who has never decided a case will either freeze, escalate everything, or guess.

Olha named the weak point herself: refund exceptions are hers, and when she's away nobody has ever decided one alone. The fix is to practise while the owner is still around. The backup takes, say, two exception cases a week, decides them, and Olha reviews the decision afterwards, not before. A short page of examples ("we said yes here, no there, and why") turns her judgement into something others can use.

Set the backup's limits in writing too: what they can decide inside the policy and what goes to Iryna. Then a vacation becomes a test the team has already rehearsed, not an emergency.

With four people, a common answer is a hybrid: a shared pool for the queue, plus named owners for a few areas, each with a backup who practises.

The pool keeps the queue flexible, which matters when vacations rotate and chat brings most of the volume. The named owners keep recurring problems owned: someone watches refund exceptions, someone keeps the help texts up to date. Rotations cover the rest: at Klasna Support, hard tickets rotate, and since late June so does the evening inbox.

This is roughly what the team already has. Olha owns refund exceptions inside the policy, and the rotations share the rest. So the real question isn't which boxes to draw. It's whether each owned area has a backup and whether each hand-off is clear. The alternatives fail a team this size: strict topics leave gaps, a channel split overloads chat, and a pure pool leaves nobody minding the problems that keep returning.

A small team doesn't need an org chart. Everyone reports to you, so boxes and lines add nothing. What people do need is a quick answer to "who do I go to for this?", especially in a summer when half the team is away at any time.

A one-page table gives that answer. One row per work area, four columns: the area (refund exceptions, help texts, video outages, the evening inbox), its owner, its backup, and who it hands off to outside the team (tutor-ops, product, finance). Link it from the team channel next to the decision log, and update it when an owner changes.

Keep things out that don't answer the question. Rankings of people create rivalry and say nothing about ownership. Long role descriptions go stale. If a row has no backup, or the hand-off column says "depends", you've found the weak spot in your structure before a vacation finds it for you.

Most delays in support happen between teams, not inside them. A video failure is a typical chain: the family writes to Support, tutor-ops reschedules the lesson, product fixes the bug. Each crossing is a chance for the family's story to get lost.

Three rules make a hand-off work:

1. One owner of the conversation. One Support person stays with the family from first message to close, even while another team does part of the work. The family never has to repeat itself.
2. A written note: what happened, what was tried, what's needed, by when. Roman from tutor-ops and the product team both complain that notes say only "see ticket"; a short template, like the three-line note the team already writes before a hand-up, fixes that.
3. An agreed reply time with the other team, set in advance, so nobody has to chase.

Forwarding a whole thread, sending the family to another team or copying everyone "just in case" all break these rules.

Span of control is the number of people who report directly to one lead. You'll hear rules of thumb, often "about seven", but there is no number that fits every team.

A workable span depends on three things: how similar the work is (eight people answering the same kinds of tickets are easier to lead than five doing different jobs), how experienced people are (new people need far more of your time), and how much time you have for one-to-ones and coaching after your own share of tickets and meetings.

In the spring you had six reports, and it felt like a lot, mostly because two of them were new and needed daily help. Eight experienced coordinators doing similar work could feel lighter. So plan the span around the time people actually need: if there's no room left for a real one-to-one with each person, the team is too big for one lead, or the lead has too much else on the plate.

A matrix structure means one person answers to two lines at once. Roman's request is a small one: a Support coordinator spends Tuesdays on tutor scheduling, Roman sets those tasks, and you stay their lead. Such setups are common and can work well, but only with clear decision rights agreed in advance.

Settle four questions before the first Tuesday: who sets that day's priorities (Roman); what happens when the Support queue explodes (an agreed rule, for example: if first replies slip past 45 minutes, the coordinator goes back to the queue and you tell Roman); who gives feedback on the scheduling work (Roman tells you, you hold the conversation); and where disagreements go (to you and Roman, never to the coordinator).

The failure to avoid is leaving the coordinator between two bosses, deciding alone whom to disappoint, or solving the clash with overtime. That turns a structure problem into one person's problem.

A new role on top of the queue, like Roman's Tuesday scheduling, is a chance to grow for someone and a risk of overload for someone else. The easy mistake is to give it to the person least likely to refuse. Olha warns against exactly that: Maryna never says no, which is a reason to protect her load, not to add to it.

Choose openly. Describe the role, ask who wants it, and frame it as a stretch with a clear end date (for example, to the end of September) and a review. Agree what comes off the person's plate on Tuesdays, name a backup, and put the arrangement in the decision log. Because it's reversible, you can say so: if it doesn't work, it ends at the review.

How it fits together: a shape for the team, named owners with practising backups, clean hand-offs, a span you can actually lead and decision rights for any two-boss setup. The case puts it all to work: July and August with two coordinators on shift, and a plan Iryna must approve.