Being the Jira admin for a small team is an unpriced tax

On a Thursday afternoon someone asks why a ticket will not move from In Review to Done. You did not build that transition and you are not sure who did. But six months ago you spent an evening working out what a screen scheme was, so the question is yours, and it costs forty minutes and whatever you were holding in your head.

Nobody appointed you. Being the Jira admin for a small team is not a role anyone takes; it settles on whoever last touched the configuration. Configurability is a cost a large organisation pays once, through a person whose job it is, and a small team pays continuously, through nobody.

The case for configuring it properly

The version of this argument that treats configurability as a defect is not worth reading. Here is the fair one.

nevinera put it plainly on Hacker News in 2015: "Jira is insanely configurable - if using jira is painful, that means that your jira admin has not configured it well for your workflow." The same comment names the trade: the amount you can turn on "can make the interface completely unusable", but that is "the cost of being able to build your own process onto the tool" (news.ycombinator.com).

The case has not aged out. On a 2026 thread, someone who had scripted Jira's API into a deploy-triggered changelog agreed: "if your team is in control of setting up Jira, it wasn't hard to keep everything on the same page" (news.ycombinator.com). A painful Jira usually is a badly configured Jira, and for two hundred people sharing one instance the configuration model is the product rather than the tax.

The Jira admin for a small team is an interruption queue

The difference between the two hundred and the five is not how much configuration each needs. It is who absorbs it.

Atlassian's own documentation hands a Jira administrator five independently configurable parts on a single transition between two statuses: triggers, properties, conditions that "control whether a transition should be executed by the user", validators that "check that any input made to the transition is valid before the transition is performed", and post functions that "carry out any additional processing required after a transition is executed" (support.atlassian.com).

Each is a place a future question hides, and answering it safely means holding the model in your head. At two hundred people that person has a job title. At five, they have their own deadline. It never arrives as work. It arrives as a tap on the shoulder. One commenter, standing in as an occasional Jira admin, wrote that changing permissions "always needs doing in 2+ places and devolves into a 'Can you see this yet?' round of questions" (news.ycombinator.com).

It compounds, and its bus factor is one

Every field somebody adds is a field the next person must understand before changing anything near it. While its author is here, that is fine.

In a 2024 thread, someone described losing their CTO, "who was also the 'jira admin' (ie. the only person who knows how the hell to do anything with jira)" (news.ycombinator.com). The opposite arrangement is no better. Another commenter, defending restrictive workflows as a consistency measure, wrote that "if you don't have a Jira admin on your team, it's impossible to build an effective and efficient workflow for your team" (news.ycombinator.com).

One person who knows is a bus factor. Nobody who knows is a ceiling.

The question is not whether the tool is configurable

It is what it costs to leave it alone, and that has a checkable answer.

Jira's is documented: "Jira has built-in workflows that you can use straight away", and "You can't edit the built-in workflows, but you can copy them and use them as a base to create your own" (support.atlassian.com).

Read as a cost model, that is generous at zero and steep at one. There is no small change. The first time the built-in workflow is wrong by a single status you copy it, and now you own a workflow — plus the scheme that binds it, because workflows "can be associated with particular spaces and, if you like, specific work types by using a workflow scheme". That indirection is what stops one team's edit breaking another's board. It is priced for a building full of teams.

Which is why the cheapest move a small team has is deciding how many columns it needs before configuring anything.

Atlassian already solved half of this

Team-managed projects exist for exactly this reader, and a small team evaluating Jira should try them first. Team-managed spaces are "Set up and maintained by anyone on the team" and "ideal for autonomous teams who want to control their own working processes and practices in a self-contained space", where company-managed spaces are "Set up and maintained by Jira admins" (support.atlassian.com).

That is a real answer and it removes the requirement for an administrator. It does not remove the accretion — statuses, fields and screens are still chosen by one person and inherited by everyone — nor the direction of travel, since the stated reason to move to company-managed is working across many spaces in a standard way. Growing into that is growing into the admin.

What "arrives configured" is worth

The alternative is not fewer knobs, but defaults somebody already decided and published.

A new Kevta board arrives with Title, Assignees, Status, Priority and Due Date on it, and the Status column already holding To Do, In Progress, In Review, Ready for QA and Done. Those five line up with the GitHub rules the board ships with; they are not neutral. You can change all of it. The point is that nothing has to be designed before the first issue exists.

The ceiling is low and near. Kevta has no transition conditions, no validators, no post functions, no permission schemes, no work types with their own workflows and no sprints. If your process requires that only a QA lead may move a ticket to Done, Jira does that and Kevta cannot. Our sourced comparison with Jira has the detail, and the wider argument about where the middle sits is in why small teams outgrow spreadsheets but drown in Jira.

So the question worth asking about a tracker is not what it can be made to do. It is what it does during the week nobody has forty minutes. We sell a tracker that takes one side of that trade, so weigh the last two paragraphs accordingly. Kevta is in beta, and you can join the waitlist.