Training your team for small teams

This is one of those topics that looks small until it costs you something. Most advice about training your team assumes a team that does not exist at your size. Here is the version that does not.

The projects that go badly are rarely the ones with the hardest technical problems. Write the reasoning down alongside the decision, because the reasoning is what changes first.

What to keep

A tool nobody can use is not a tool. Small and consistent beats large and occasional here. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. That sounds obvious written down. It is still the thing most often skipped.

How we handle it

Training beats documentation people never open. This is the sort of thing that compounds, quietly, in both directions. Check it against what you would want a competitor's site to get wrong.

In practice

Clear scope protects the client at least as much as it protects the agency. Three things worth confirming about training your team before you move on:

• Someone can say what the current setup is without going to look
• A tool nobody can use is not a tool — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.