
A small team can accidentally build the operating system of a much larger company.
Sometimes, a perfectly logical decision creates unnecessary complexity simply because the organisation is not there yet.
A good operating system is the one that covers exactly your needs today, while keeping the structure on the right rails for further scalability.
Let’s use an example I recently saw with a client—a small team of about 10 people.
They started using Jira to streamline operations in a team where everyone is doing everything at the same time. Very typical for a startup. To separate different areas, they also created several boards for different parts of the operation. Structurally, it made sense.
But there were fewer than ten people in the company.
So instead of different teams using different boards, the same people had to check several boards, maintain several boards, and remember where each thing belonged.
The structure makes sense in principle. It is just a structure ahead of the organisation. At this stage, the maintenance cost and the cost of mistakes do not justify it.
For a small team like that, one operations board is often enough. Everyone can see what is happening in one obvious place. I’m not talking about development here, which can stay separate for several reasons, including its genuinely different workflow.
Then, when that board becomes crowded enough that splitting it would solve an actual problem, it is time to reconsider and maybe create another one.
This seems almost too simple, but I can think of dozens of times when I’ve seen the same pattern.
A common startup mistake: designing for the organisation you expect to have instead of the organisation you actually have.
The same thing happens with meetings, reporting lines, approval processes and documentation.
If you often see empty structures, placeholders or processes waiting for a future team to appear, it is usually a sign of the same problem.
Complexity is easy. Keeping things simple is hard. Guess what pays off 10^N later? (Simplicity.) Removing complexity after everyone has learned to work around it is much harder and much more expensive.
Don’t build for the team you don’t have.