Jira is an MLM
Jira’s “Agile Project Management” tool (referred to as Jira, herein) is almost none of the things it claims to be, and hasn’t ever been.
To ensure there is a clear distinction, Jira’s Service Desk Management offering is quite solid and well supported by case studies. So when I refer to “Jira”, I am specifically referring to its “Agile Project Management” tooling, ie. Jira as a “software project management tool”.
I want to make the argument that Jira is actually an MLM. And this may sound tongue-in-cheek, but I’m quite serious.
Have a read and make your mind up for yourself if I’m making a solid point or a stretch.
First, let’s get one thing straight.
Jira is NOT a project management tool
The primary landing page refers to it as a “project management tool”, and already we’re off to an absolutely egregious lie right out of the gate.
Here is a rough comparison of Jira to Rapid Platform, which is actually project management software:
| Feature | JIRA | ”Rapid Platform” (Real PM Software) |
|---|---|---|
| Task Ownership | Exactly one assignee per issue. Secondary contributors are just “watchers.” | Supports multiple resources per task, with clear roles (e.g., lead, reviewer, contributor). |
| Resource Management | No native resource tracking - can’t see who is overbooked, underutilized, or when specific skill types are saturated. | Built-in resource allocation: track effort by hours, roles, or percentages across projects. Prevents overloads. |
| Timelines & Dependencies | Gantt charts and dependency mapping are awkward / plugin-based. Dependencies are mostly “linked issues,” which don’t automatically affect timelines. | Native Gantt/roadmaps: dependencies automatically adjust schedules; slippage cascades visibly across the plan. |
| Workload Forecasting | Velocity charts for agile teams only; no real forecasting of delivery dates outside of burndowns. | Predictive scheduling: shows expected completion dates, flags resource bottlenecks, models “what-if” scenarios. |
| Goal Alignment | Epics and initiatives exist but are weakly tied to actual deliverables; no hierarchy beyond custom setups. | Portfolio hierarchy: projects → programs → initiatives → tasks, with traceability from goals to execution. |
| Collaboration | Comments and @mentions exist, but threaded discussions are clunky; collaboration mostly offloaded to Slack/Confluence. | Real-time collaboration inside tasks (shared docs, chat, whiteboarding) directly tied to work items. |
| Usability | Steep learning curve, cluttered UI, heavy configuration needed. | Designed for fast adoption; drag-and-drop scheduling, simple dashboards. |
| Reporting | Burndown, velocity, cumulative flow - mostly agile-centric; advanced reports require add-ons. | Rich cross-project reporting: resource utilization, budget vs. actuals, milestone tracking, risk heatmaps. |
| Flexibility vs. Consistency | Extreme configurability → every team has different workflows → fragmentation. | Balanced templates enforce consistency while allowing some customization. |
| Outcome vs. Output Focus | Optimized for tracking tasks completed. Hard to see impact on overall goals. | Designed to track outcomes (deliverables, milestones, KPIs) alongside tasks. |
Jira began as a bug tracker - as such its fundamental unit of work is the ticket. A ticket is a single, easily describable piece of work. How much of the work we do day-to-day in software fits this model? Very little, is the answer. Or, at least, it only becomes describable in retrospect.
Jira is not a project management tool - it’s a support desk tool, a bug tracker, at most a to-do list. It works fine for tracking, but so does git and a good PR description. Why bother?
This idea of the ticket is the fundamental flaw of Jira as a software project management tool: the work that’s easily ticketable is the work that gets ticketed. So all the stuff that’s actually hard and takes time never makes it into Jira, giving you this picture of your software org that things like bugs and tech debt are overwhelmingly absorbing your org’s time. But this is actually just because a) these are easy to describe; and b) mostly engineers are using Jira.
And this is where we start to see Jira as an MLM - it all begins with illusory value.
Illusory Value: Jira produces nothing
Why is it, so often, that people who don’t like Jira move back to using a spreadsheet? The answer is because Jira doesn’t produce anything. It’s effectively a glorified spreadsheet that parrots back whatever you put in.
“It produces reports!” says the advocate. Yes, but meaningless ones. They inherit that bias I already mentioned - they only reflect what was easy to ticket. Which means they miss all the real innovation, collaboration, and messy, creative work that doesn’t fit the “Todo → In Progress → Done” model. Jira produces no value beyond the illusion of control.
Jira is the placebo pill of project management. Teams improve because of the practices they adopt - standups, retros, iteration - but Jira takes the credit for the cure. Like snake oil that “works” only because belief does the heavy lifting, Jira thrives on the illusion that the tool itself was responsible.
Like essential oils or bogus vitamins, the “value” comes from the ritual and the belief. And, just like those products, it can actively damage people - in this case by misleading whole organisations about what’s actually happening in their engineering teams.
And once you’ve bought into that illusion, the pyramid begins to grow.
Enforced Recruitment: Jira builds pyramids
Every new Jira project or instances pulls more people into the illusion, whether they want to or not. Ever heard the term “JIRA Champion”? The snake oil is sold on the idea that “Jira works if everybody uses it correctly” - so everybody must be forced in.
When someone decides to use Jira, they inevitably drag others in - “we can’t manage these projects unless you log tickets”. In MLM terms this is enforced recruitment. Usage expands not because it works, but because the system demands expansion to justify itself.
The successful use of Jira is never measured in any real terms, how could it be? The success is measured on how big the pyramid is, how many tickets, how many people are using the tool. Given there’s often no way for an org to actually verify any output Jira is giving them in terms of reporting on the org’s activity, how can they possibly know that it’s doing what was promised? Hint: it’s not. It just looks like it is because it produces something (no, I did say MLM, not LLM, but you’d be forgiven for the mistake!).
A simple look at their website will show you there are plenty of case studies for Jira Service Desk Management, but conveniently none for Jira’s “Agile project management” tools.
Once the pyramid is big enough, the metrics themselves become the work.
Evangelism: Spread the Good News
Like an MLM, Jira thrives on evangelism. Just like those essential oils you tried to tell your aunt were a scam, Jira thrives only through recruitment of more people to the pyramid, who then do the work of convincing themselves their purchase was a good decision - perhaps to avoid the embarrassment of admitting that highly concentrated bergamot oil is essentially poison.
There are “Atlassian Evangelists” who run training sessions and conferences - just like Amway rallies or Herbalife conventions. And just like MLMs, it’s those who’ve invested that often become the loudest advocates, telling others they “just don’t get it” or “they’re just not using it right”, etc.
At its most insidious, this becomes a dogma along the lines of “if it’s not in Jira, it didn’t happen”. Which brings us to the warped incentives that Jira creates.
Misaligned Incentives: Outputs over outcome
So called “work” tracked in Jira is never measurable in outcomes, only in output. The number of tickets, the number of points, are the tickets up-to-date, etc. This is disastrous for high-performing, innovative organisations as it inherently rewards people not even based on the amount of work they do, but the amount of work they do in Jira!
Just like an MLM incentivises recruitment over selling a product, Jira incentivises creating and updating endless tickets under the illusion that they represent real work. It rewards the appearance of productivity rather than impact.
Here’s a hot tip for engineering leaders: the people actually driving outcomes aren’t in Jira all day. You know this, because you don’t live in Jira either - you delegate it. The real work has never been in Jira, and never will be.
When the optics become more important than the outcomes, you end up with my least favourite ‘b’ word: bureaucracy.
Endless Hierarchy: Fractal bureaucracy
Jira, like an MLM, generates endless hierarchy. Tickets have subtasks. Subtasks roll into epics. Epics into initiatives. Each new layer promises clarity, but just creates more overhead.
It’s not just tickets. People themselves get caught in hierarchies of project admins, Jira admins, instance admins. You can’t just use Jira - you need a bureaucracy to run it.
None of these layers are measured on actual outcomes. Just on the size of the pyramid beneath them.
Extract Value: Draw money upward
At the end of the day, MLMs aren’t about selling vitamins or essential oils - they’re about funneling money upward. The product is just a front. The real “value” is in the continuous recruitment and the constant spend of those at the bottom.
Jira works the same way. Atlassian’s profits don’t scale with outcomes delivered, or projects completed - they scale with headcount. Every new hire means a new Jira seat. Every new project means another instance. Every migration means more consulting, training, and certification programs. Then there’s the entire Atlassian Marketplace, a cornucopia of plugins you’re suddenly “required” to buy just to paper over Jira’s missing features.
It’s a machine designed not to help you build software faster, but to keep you locked in and paying forever. Like Amway, Herbalife, or any MLM, the wealth accrues at the top. Atlassian grows fat while your teams drown in overhead.
So who’s winning here? Not your engineers. Not your projects. Only the people selling the dream.
Summary: Jira, A Promise Unfulfilled
Jira has never delivered on any of its promises beyond bug tracking.
Boards and workflows and sprints trip up the team and end up becoming pointless busywork - “oh, we just need a new ticket type / a new board / kanban”!
Reports give meaningless, inaccurate information - “oh, we just aren’t using story points and epics right”!
Every project or team becomes its own nightmare tangle of hierarchies and relationships - “oh, we just need to all use the same workflow”!
It’s always “we just need x…”. Jira locks us in with no escape - Atlassian have recruited the CTO, the PM, whoever it is, and that person now has a bunch of snake oil they have nothing to do with. They’re not going to go and admit they wasted everyone’s time and money and dump it in the trash and move on, are they? No, they’re going to double down - “I still believe, just one more instance and we’ll get it right this time…”.
When are we going to stop listening? When are we going to finally wake up as an industry and stop buying into this nonsense?
So, what have we learned?
Jira:
- Is not a project management tool
- Expands internally through compulsory recruitment
- Becomes its own work, rather than helping manage it
- Incentivises output and “optics” over outcomes and impact
- Locks participants in and makes it difficult to leave
- Employs cult-like evangelism in order to spread its influence
- Drains money from the bottom and drives it upward
In the end, Jira is a placebo of project management: the real improvements come from process and practice, but the tool takes the credit - and Atlassian cashes the check.
And that, dear reader, is why Jira is an MLM.
Addendum: Can Jira's value be proven?
Unlike a drug trial, you can’t blind a team to the tool they’re using. The only way to test Jira’s impact would be to A/B teams on Jira vs. spreadsheets vs. Trello - but then you’re mostly measuring how clunky or pleasant the tool feels, not whether it drives better outcomes, because you can’t make (fair) direct comparisons across teams.
This is why Jira’s defenders always fall back on the same line: “it only works when the whole org buys in.” Which makes the claim unfalsifiable - any failure can be explained away as poor adoption. In other words, Jira’s value can’t really be proven, only believed.