Why small teams outgrow spreadsheets but drown in Jira

There is a stage almost every small team passes through. Someone opens a spreadsheet, adds columns for What, Who and Status, shares it, and for a few months it is the best project management tool the team has ever had.

Then it stops working. Not suddenly, and usually not for the reason people give when they finally replace it.

What the spreadsheet is genuinely good at

Worth saying first, because the standard failure of essays like this one is to describe the thing you are leaving as obviously broken. It isn't.

A spreadsheet has three properties that most purpose-built trackers give up:

• It has no opinion. Any column you want, named whatever your team already calls it, in whatever order makes sense this week.
• Setup cost is zero. No projects to create, no workflow to define before the first row can exist.
• Everyone already knows it. There is no adoption curve, because there is nothing to adopt.

For three people working on one thing, that combination is very hard to beat, and a team that stays on a sheet longer than the internet says it should is usually making a reasonable trade rather than a mistake.

The three things that break

The useful version of "it doesn't scale" is specific.

A row has no identity. You cannot link to it. So when someone wants to discuss it, the discussion happens somewhere else — a thread, a call, a comment on a pull request — and the sheet quietly becomes a summary of decisions taken elsewhere instead of the place they were taken. Nothing about the sheet failed. It just has no address to point at.

Nothing remembers. A cell that says "Done" contains no evidence that it ever said anything else. The questions you eventually want to answer — how long does work sit in review, who moved this to high priority, what did we say we were doing in March — are unanswerable, because the sheet only ever holds its current state. Spreadsheet version history technically records the change; try using it to answer any of those three questions.

The schema drifts. Everyone who touches the sheet adds the column they personally needed. Six months in there are three columns that all mean status, two date columns nobody can distinguish, and a convention that lives entirely in one person's head. There is no schema to violate, so nothing objects.

There is a fourth, quieter one. Spreadsheets in operational use contain more errors than the people relying on them believe. Ray Panko's summary of the field-audit literature reports that the five studies with the strongest methodology audited 55 operational spreadsheets and found errors in 91% of them, and that across nine inspections covering 163 spreadsheets, 84% contained errors (panko.com/ssr/Audits.html). Most of those audits looked at financial models, and a tracking sheet with no formulas in it is a far smaller target — so the honest version of this point is not "your tracker is riddled with bugs". It is that a spreadsheet gives you no way to find out whether it is. The error you actually hit is a filter someone left on, or a sort applied to one column and not its neighbours, and the document has no opinion about either.

Then someone says Jira

The instinct behind that suggestion is correct. The team does need identity, history and a shape. The overcorrection is what causes the trouble.

Jira is not bad software. It is software built to stay correct at a scale you do not have. Atlassian's own plan documentation puts the paid tiers at up to 100,000 users (support.atlassian.com), and essentially everything about the configuration model follows from that number. Behaviour in Jira is assembled out of schemes: a workflow scheme maps workflows to work types, a screen scheme decides which fields appear on which screen, a work type screen scheme maps those screens back to work types, and then field configuration schemes, permission schemes and notification schemes each layer on top (Atlassian's admin documentation, permission schemes).

That indirection is the right answer when four hundred teams share one instance and each needs its own bug workflow without disturbing anyone else's. It is a strange answer when there are five of you and one workflow. The marketplace points the same way: Atlassian's developer platform advertises 6,000+ apps and integrations (developer.atlassian.com). An ecosystem that size exists because the base product is a platform most customers are expected to extend. At enterprise scale that is a strength. At five people it is a warning, because the implied second step of every setup guide is "and then you configure it".

And the cost of Jira is not the licence. The Free plan covers up to 10 users (support.atlassian.com), so a five-person team pays nothing at all. The cost is that one of those five people becomes the Jira administrator — the one who knows why the transition is blocked, why the field isn't showing on the create screen, which board the sprint is actually on. That role is real work, it is nobody's job, and it comes out of the same week you were going to ship in.

The middle is smaller than people expect

Between "a shared sheet" and "a configurable work-management platform" there is a list of capabilities, and it is short:

• Every item has a stable identifier you can paste into a message, a commit or a pull request, and it still resolves to the same thing next year.
• Every item has one owner and one status, and the set of statuses is small enough to hold in your head.
• The discussion about an item lives on the item.
• Every change is recorded, with who and when, without anyone opting in.
• Each person can see only their own work without building a filter first.
• The same work can be read as a board or as a list, without exporting anything.

That is close to the whole thing. Not because nothing else is useful — story points, dependency graphs, capacity planning and portfolio roll-ups are all genuinely valuable to teams that need them — but because none of it is load-bearing at five people, and every one of them costs a decision, a convention, and a recurring conversation to keep alive.

"We'll grow into it"

The strongest argument for adopting the heavy tool early is that migrating later hurts. It deserves examining, because it is usually backwards.

Migration cost scales with how much you have accumulated. A team of five that has been tracking work for a year has hundreds of issues, not hundreds of thousands, and roughly one workflow to carry across. Most of those issues are closed and do not need to move at all, which usually leaves a few dozen open items and one set of conventions to agree on again. The migration people are actually afraid of is the one they would face in five years — and by then they would be moving off whatever they chose today anyway, because requirements change faster than tools do.

The cost of the other direction is paid continuously and never shows up as a line item. Configuration you don't need is still configuration you maintain: fields nobody fills in, statuses nobody uses, notification rules set up by somebody who has since left.

Disclosure

We build an issue tracker, so treat the framing above with the suspicion it deserves. Kevta is our attempt at exactly this middle — issues with stable keys and full history, board, list, table and calendar views over the same work, and deliberately little to configure. It is in beta, and it is the wrong answer for a team that genuinely needs schemes and portfolio planning. When you need those, Jira is very good at them.

The point that holds regardless of what you pick is the question itself. Not "which tracker is best", but "what is the smallest thing that gives us identity, history, and one status column we all agree on". Answered honestly, that makes the shortlist very short.