Why Every Engineer Hates Jira (And How We Made It Worse)

Brian Sierakowski - Founder

Every engineer I’ve ever met has a complicated relationship with Jira. Some actively despise it. Others have resigned acceptance. Almost none would describe it as a tool that helps them do their best work.

How did a project management tool become the most resented piece of software in engineering? The answer isn’t about Jira itself. It’s about what we did to it.

The Centrifuge Problem

Here’s what happened at every company I’ve worked at:

  1. Engineering starts using Jira to track work
  2. Sales asks: “Can we know when features are shipping?” → Add a field
  3. Support asks: “Can we know which tickets relate to customer issues?” → Add a field
  4. Marketing asks: “Can we know what’s customer-facing vs. internal?” → Add a field
  5. Finance asks: “Can we track time for billing?” → Add a field
  6. Legal asks: “Can we flag compliance-related changes?” → Add a field

Each request was reasonable. Each field made sense in isolation. And collectively, they transformed Jira from a work-tracking tool into a data-entry burden.

A VP of Engineering at a workplace software company described engineers as “burdened by extra Jira/form work to surface what’s shipped.” The form fields exist because other teams need visibility. But the cost falls entirely on engineering.

The Tax Nobody Calculated

When you add a required field to Jira, you’re adding a tax on every piece of work that flows through the system.

Let’s say filling out the new field takes 30 seconds. Sounds negligible. But multiply that by:

  • 50 engineers
  • 20 tickets per engineer per week
  • 52 weeks per year

That’s 8,667 hours of data entry per year. For one field.

Now multiply by the 15 custom fields your organization has added over the years. Suddenly you’re looking at tens of thousands of engineering hours spent not on engineering.

And that assumes everyone fills out every field. In reality, engineers skip fields whenever possible. Which means the data is incomplete. Which means whoever requested the field doesn’t get what they need. Which leads to meetings to fill the gap. Which adds more overhead.

Why Engineers Don’t Fill Out the Fields

The fundamental problem is incentive misalignment.

The people who need the information (sales, support, marketing, leadership) aren’t the people who have to enter it. The people who have to enter it (engineers) gain nothing from doing so.

An engineer finishing a feature is thinking about the next thing to build, not about updating a field for some downstream report they’ll never see. The field is friction between them and their actual work.

This behavior is rational, not lazy. Every organization gets the data entry quality it incentivizes, and most organizations incentivize shipping code, not filling out forms.

The Workarounds That Make It Worse

When required fields don’t get filled out properly, teams create workarounds:

More meetings. “Since we can’t trust the Jira data, let’s have a weekly sync to walk through what’s shipping.”

Shadow tracking. Product managers create their own spreadsheets to track what’s actually happening because Jira doesn’t tell the full story.

Double data entry. Someone (often a PM or TPM) manually updates Jira based on what they learned in the meeting or from the spreadsheet.

Each workaround adds overhead. None of them solve the underlying problem: engineering’s work output isn’t automatically connected to the information other teams need.

The Bigger Issue: Wrong Layer of Abstraction

Jira captures intent: what we plan to work on. It doesn’t capture reality: what actually shipped.

A ticket might say “Build Slack integration.” But that doesn’t tell you:

  • When did it ship?
  • What exactly does it do?
  • Which customers care about it?
  • How should support talk about it?
  • What’s the marketing angle?

These questions require context that doesn’t live in the ticket. The ticket is a pointer to work, not a description of outcomes.

Every field you add to Jira is trying to force that context into a place it doesn’t naturally fit. Engineers aren’t writing detailed release notes in Jira fields because that’s not what Jira is for. It’s a work management tool, not a communication platform.

What Would Actually Help

The solution isn’t better Jira hygiene or more disciplined field population. The solution is removing the need for manual data entry altogether.

What if the information other teams need came automatically from the work itself?

The code tells you what changed. The commit tells you when. The PR tells you why. The pattern of changes tells you what kind of change this represents (new feature, improvement, bug fix).

If you can extract that information programmatically, engineers never have to fill out fields. The data is accurate because it comes from the source of truth: the code. And the information is timely because it updates automatically when code ships.

This isn’t hypothetical. The raw material exists in every engineering organization. The question is whether you have a system that can turn it into actionable information for other teams.

Reducing the Tax

If you can’t remove manual data entry entirely, at least reduce it:

Audit your fields. How many custom fields does your Jira have? How many get used? How many generate reports anyone reads?

Question new requests. When someone asks for a new field, ask: What decision will this data inform? Is there another way to get that information?

Make fields optional. Required fields that engineers skip anyway just create bad data. Optional fields with clear purpose get filled out when relevant.

Consider the cost. Before adding a field, calculate the actual time cost across the organization. Is it worth 1,000 engineering hours to get that data?

Look for automated sources. Can you get the same information from GitHub, deployment logs, or analytics without asking anyone to enter it manually?

The Path Forward

Jira didn’t become hated because it’s a bad tool. We made it hated by turning it into the universal interface for all cross-team information needs. That’s not what Atlassian built it for.

Engineers should be able to focus on building. Other teams should be able to get the visibility they need. These goals don’t have to be in conflict.

The answer isn’t asking engineers to be better at data entry. It’s building systems that capture the information automatically, at the source, without human intervention.

Your engineers are expensive. Stop making them fill out forms.

If your team is drowning in Jira fields and meetings, let’s chat about how Changebot extracts the information directly from code.