Dividing roles in a small team

Why divide at all

So the same thing isn't built twice and so every part has an owner. A part with no owner doesn't get built: everyone assumes it's someone else's.

But dividing in a small team isn't the same as job titles at a company. Here, ownership of a piece matters more than the name of a role.

Approach one: by product area

Each person takes a scenario in full and builds it end to end, from storage to screen.

Upsides. Nobody waits for anyone. Everyone sees the result of their work. Ownership is clear: if a scenario is broken, you know who to ask.

Downsides. Everyone needs a little of everything. The pieces may come out stylistically different.

For a team of beginners this is the best available option, precisely because of the independence: waiting on each other is the main cause of a project stalling.

Approach two: by layer

One builds what the user sees, another builds what's underneath.

Upsides. Each works in their own area and grows deeper.

Downsides, and they're serious. The first constantly waits for the second. The second builds things that stay invisible for a long time. If one disappears, half the project is unusable.

It suits people with genuinely different skills who have experience agreeing the seam in advance.

Approach three: everyone does everything

A shared task list; each takes the next free item.

Upsides. Flexible, everyone understands everything, nobody is irreplaceable.

Downsides. It needs discipline and a board, or two people build the same thing. And ownership is harder: when something breaks, it's everyone's.

It works in teams of two or three at similar levels.

Roles beyond the code

Every project has work nobody wants and that is nonetheless mandatory:

• Watching the whole. How the parts will assemble.
• Keeping the task list honest. So the board reflects reality.
• Talking to the people you're building for. Showing it, collecting reactions.
• Handling releases. So the project is reachable, not only on laptops.

Assign these explicitly. "It'll sort itself out" doesn't: these things get done by whoever finds it unbearable first, usually the same person, who then burns out.

When everyone wants the same part

The usual situation: three people want the interface and nobody wants the data.

What helps:

Rotating. One stage you do the dull part, the next the interesting one. Works if stages are short.

Splitting in half. Everyone has an interesting part and their share of the dull one.

Saying it out loud. Sometimes an honest "this bores me, but someone has to" resolves more than any scheme.

What not to do is quietly leave the unattractive part with the most obliging person. In a month they leave.

Checking the division works

• Every part has a name against it.
• Everyone can say what they're doing this week.
• Nobody waits on anyone for more than a day.
• Someone is watching the whole.

If any of these fails, the conversation is worth reopening. Fifteen minutes now is cheaper than a month of misunderstanding.