> ## Content Index > Fetch the complete content index at: https://valdivya.com/llms.txt > Use this file to discover other available public pages before exploring further. # Fixing Jira Starts with Change Management, Not a New Tool - URL: https://valdivya.com/fixing-jira-starts-with-change-management-not-a-new-tool/ - Published: 2026-08-06T12:00:19.000Z - Updated: 2026-08-06T12:00:19.000Z - Description: If your team has given up on Jira, the tool isn't what needs fixing. · Start here → - Author: Jesse Hormachea - Tags: Atlassian, Jira, all --- ## Key Takeaways - **Jira's problems are rarely about the tool.** Switching platforms just moves the same unmanaged mess somewhere new. - **Jira should reflect how your team actually works,** not how the person managing it thinks it should work. - **Every change has a cost.** More fields and statuses mean more clicks, more training, and more confusion, even when each one seems small on its own. - **Someone has to own Jira, and the whole team needs to know who.** Without clear ownership, the tool drifts until no one remembers why it's there. - **A Jira reset starts with agreement on principles,** not with rebuilding workflows. The framework comes after the team is aligned on the why. --- While working with Jira for over a decade, I’ve heard every complaint and excuse for why Jira doesn’t get used. It’s too complex. It’s too messy. It’s too inefficient. The UI is confusing. If you spin up a brand new instance of Jira, it’s anything but that. You get simple project boards with To Do, In Progress, Done. You get a few fields to fill out to enter a ticket. Your task list is front and center in the For You screen. You can get to work. ### So what makes Jira such a dirty word for software, support, and operational teams? It’s the way it’s managed. Typically, Jira is a footnote in someone’s job description. They are a project manager and the Jira admin. They are the manager and the person that does Jira. Someone picks it up because *someone* has to manage it. They’ve never administered it before, but they can figure it out. It’s easy to add a field. It’s easy to add statuses, workflows, and make fields required. They get requests to add a field, and of course, it’s so easy, why not do it? Suddenly, your board requires you to scroll horizontally. Your workflow statuses are spaghetti and no one can figure out what the steps are or even how to close a ticket. All those required fields has your team just pinging you with issues since they don’t have all the answers to complete the form. It’s just easier to send a direct message and you’ll take care of it. The team stops updating the board and you start doing it. Suddenly Jira is for the one person that manages Jira to keep everything updated. No one knows why Jira is involved. ### Does any of this sound familiar? Similar to other complex business systems, Jira needs a strategy. It’s no different than the problems that arise in a CRM, HRIS, Payroll, ERP, CMS, and other business operations tools. ### Without a strategy and the expertise, you build the exact mess you didn’t take the time to plan for. Many people at this point blame the tool and start evaluating another solution. Trust me. I’ve worked in enough other tools and systems and the reason Jira isn’t working for you is not about the tool. The problems you have in Jira will follow you to whatever is next. That said, a reset is the place to start. To start the strategic thinking for any operations tools, you need to start with the why. Why are you needing a tool to solve this problem? Something like... *My team needs a collaborative tool where we can see future work, completed work and in-progress work.* Once you’ve identified your why, it’s time to build some principles that will hold up your strategy. ## Four Pillars of a Jira Strategy 1. **Jira is your team’s work context.** It’s not just a checklist. This one is incredibly important as AI tools mature. AI-based agents and people need to understand their work, how it fits into the broader context of the project, and have a clear place to communicate. If people just feel they move disconnected tasks through a board for their project manager, it’s not serving the purpose of understanding their work. 2. **Jira should work for your team. Not against it.** This point is the fatal flaw I see across systems designed by the business, management, or operations focused roles. They are managing the system so they build a system that works how they do. The problem is that isn’t typically how the members of the team want to break down tasks, capture information, or provide updates. When Jira is built for the team, task entry is simple and the uses the minimum information needed. Workflows and statuses are simple and clear. 3. **Every change has a cost.** Just because you can, doesn’t mean you should. That extra status step might make you envision a nice report but it’s more clicks for your users, more training to understand it, and more clutter in your UI. This pillar is one of the hardest because no is hard. You feel like a monster blocking what might feel like forward progress for an individual but future confusion for the team at large. No is not a four letter word. 4. **Clear ownership, governance, and clean up cycles.** Jira has to change and evolve with your team. The ownership of Jira needs to be clear. Everyone knows how change happens, not just who is in charge of making a change. On the surface, these pillars seem simple but I’ve worked with teams of 10s to 1000s in Jira and other systems where each of these topics generates strong conversations. Everyone has their favorite field, status, or workflow that they can’t imagine living without. Most teams don’t even know what the capabilities out of the box are so I’ve seen lots of circles to create something that already exists. If this sounds like your team, this is the type of work I am passionate about. I help teams build the strategy and governance behind Jira, so the tool serves the work instead of the work serving the tool. [Start your change management journey](https://valdivya.com/contact/)