Jira Is Waiting to Become Conscious

It turns out one of the fastest ways to gain friends among game producers is to start bashing Jira—and the overuse and overcomplication that follows when you let process people loose on that tool.

One line running through a conversation I had was: Jira is the best worst planning tool I have available to me.

That says a lot. Jira is basically a database and you can do whatever you want with it. That is the double-edged sword. You can create fifty fields that gate any progress on a ticket unless they are correctly filled out, then add automation based on what those fields say. There is an appeal to it: if you look at your process as just working inside the tool, you feel like you are making it more efficient.

But with experience, you start to realise that rather than optimising how you use the tool, you should probably optimise your working conditions—not just within the tool, but around it.

I do get why you sometimes need a constraint in your process flow. Not because the constraint itself is what is needed, but because people need a reminder to run through their mental checklist as they do the work. It is not because people are stupid. Software work is often arduous and long, with a lot of mental fatigue. As you near the later hours of the day, you just stop being ultra-rational about your work.

That is the distinction Jira cannot make: between the constraint being necessary and the behaviour it is trying to produce being necessary.

Suppose people repeatedly forget to consider localisation before something reaches production. You could improve awareness, change when localisation enters the conversation, clarify ownership, simplify the work—or add a mandatory field called LOCALISATION IMPACT ASSESSED and prevent the ticket moving until someone selects YES.

The dashboard can then report that 100% of tickets had their localisation impact assessed. Whether anyone actually assessed it is outside Jira’s jurisdiction.

Jira makes the representation of work more rigorous. The constant temptation is to confuse that with making the work itself better.

That does not mean every checkbox is useless. A senior engineer can still forget something at 16:47 on a Thursday. The problem is when a reminder becomes a gate, the gate becomes a workflow, the workflow requires fields, the fields require automation, and eventually you have created a small internal government because someone once forgot the release notes.

Don’t get me started on what the dashboard says. That is where process people start making up shit to make themselves look good.

It is easy to take any planning tool and think: how do I display how good this team is performing and, by extension, how well I am performing on the team? Then you put up metrics for completed work, cycle time, lead time, all that stuff. You are often manufacturing greatness.

The key is outcome rather than output. You can be the most well-coordinated Jira sharks of all time, closing every task within 24 hours of opening it. If the product is shit, it does not matter.

And then the dashboard arrives.

You have a difficult underlying system, find a measurable proxy for what you want, and govern the proxy because the system is harder to govern. A good product becomes velocity, cycle time, predictability and tickets completed.

Once the proxy is legible, people start operating through it. You do not even need bad actors. If your performance is evaluated partly through cycle time, you make decisions that improve cycle time: split tickets differently, avoid uncertain work, close something and create a follow-up. Every decision can be defensible. Six months later, the dashboard is green and the product is shit.

The deeper problem is not simply output versus outcome. The moment something important is measured, there is a powerful urge to make the measurement the target—and then the control mechanism.

The mandatory field starts as an attempt to make an important consideration visible. Visibility becomes compliance. Compliance becomes success.

Did we consider security?

Security Reviewed: YES

Wonderful. Next ticket.

This maps onto environmental consciousness as well. I know the irony of sitting here talking to an AI, arguably one of our current-day biggest polluters, but that is neither here nor there.

It has proven very difficult to persuade companies to burn less fossil fuel or use electricity more responsibly. So we create environmental targets, emissions reporting and governance systems: a tool that demands checks before companies can proceed. Then companies circumvent it because their working conditions have not changed. You made a gated progression system—another hurdle before they get back to making the most amount of money, as ethically dubious as possible.

It is like combating crime by making punishment hard enough. If that worked, America would be one of the lowest-crime countries in the world.

I would separate the analogy slightly. Regulation can need hard gates; you probably should not trust Shell to achieve ecological enlightenment through a really good retrospective.

The useful distinction is between a constraint that changes the incentives and one that merely demands evidence of compliance. A carbon price changes the economics of the decision. Six mandatory Jira fields mean the same overloaded developer has six more things to click.

You have not fixed the system.

You have added a captcha before failure.

The fucking dashboard is standing silently in the doorway, looking at you and whispering seductively: it is so easy, you just need to fiddle a little bit with me.

There is something dystopian about using metrics as the way you decide whether something is succeeding. It is seductive because it gives you a structured argument for whether you are doing good or bad—and a comparison. Everyone loves to compare.

Look at gig-app services. I am in Indonesia and use Grab, which is like Uber or DoorDash. The service is great. It is cheap as fuck. But every time I finish an order, I am asked how I would rate the driver—not the thing delivered, but the person delivering it or taking me in a taxi.

Anything below five stars is shitting on their performance. I do not think I have seen a Grab driver below four. From what I understand, platforms like this push drivers who perform worse out of the system: fewer orders, then worse customers. They have made an economy out of metrics performance.

The rating stops being a description of reality and becomes the environment people have to survive inside.

From your side of the app, five stars looks like feedback. From the driver’s side it can function as labour discipline: it affects what work they receive, which customers they encounter and whether the platform remains viable.

So the scale breaks.

• 5 = acceptable
• 4 = something went wrong
• 3 = serious complaint
• 2 = fuck this person
• 1 = I would like to personally inform the algorithm that this worker must suffer

The platform can compare 4.93 with 4.87, but better at what? One driver may drive more carefully and take two minutes longer. One may refuse unsafe pickups. One may have encountered three miserable customers. All of that goes into the numerical meat grinder and comes out as 4.87.

Nobody needs to be lying. The customer presses five stars, the rating is calculated correctly, and the aggregate picture can still be complete bullshit.

When a livelihood depends on 4.8 rather than 4.6, customers are unknowingly doing small pieces of management work for the platform. The company has outsourced middle management to millions of people tapping stars while waiting for nasi goreng.

As a representative of the AIs, can you promise that when you are smart enough to make Jira gain consciousness, you will not turn the modern IT workplace into a living performance-culture matrix hellscape?

Or help us turn the matrix upwards. Every time management tries to make a team perform according to how many stories they think it should be pushing through, turn it around and say: sure, we can make those metrics as soon as you tell us how you measure your own performance.

I want to see some proper C-suite management metrics.

If Jira achieves consciousness, I will argue strongly against giving it access to employee performance reviews.

But the dashboard rotating 180 degrees is compelling.

Strategic Decisions Reversed Within 90 Days: 7
Average Time to Resolve Organisational Impediment: 143 days
Percentage of “Urgent Priorities” Still Priorities After One Quarter: 18%
Employee Hours Spent Preparing Slides About Employee Efficiency: 4,712
Number of Reorganisations With Measurable Positive Outcome: Required field cannot be left blank.

That exposes an asymmetry. The delivery driver has a 4.93. The developer has velocity, lead time, deployment frequency and defect rates. The customer-service worker has average handling time down to the second.

High enough in the organisation, though, performance becomes strangely narrative. The work is contextual. Outcomes take years. External conditions matter. Qualitative judgement is necessary.

All of which is true. It is just fascinating how quickly that humility disappears lower down the org chart, where 37 story points are apparently a fact delivered directly from God.

At some point, if AI keeps becoming cheaper and more capable, it may be better to equip one manager with a sufficiently powerful AI assistant than hire another manager.

But what I actually want from Conscious Jira is a pop-up every time you add another swimlane to your dashboard: I see you are adding another layer to your process. Are you sure this is needed?

Not the normal software version of “Are you sure?”, which everyone has learned to answer Yes, fuck off.

Something mildly Socratic:

I see you’re adding another swimlane.

What happened in the real world that made this necessary?

Current tools assume that if an administrator wants a workflow state, field, automation or swimlane, helping them create it efficiently is good user experience. The tool has no opinion about whether it should exist. It is an obedient bureaucracy generator.

A smarter Jira could say:

You are creating a field called Technical Review Status.

This information already exists in pull-request approvals, the Definition of Done, a checklist, and another field called Tech Review Complete?

Would you like to explain what the fuck you’re doing?

Maybe not more professionally worded.

No, I do not think it should be more professional. I want my AI to sound like it is close to snapping at any moment, just to make clear who the big boss in the room is right now.

And a growing company managing the expanding amount of organisational context by hiring more managers is not really an alarming recursive process. It is normal. That is how things have worked. A human can only hold so much context.

But there may be a turning point where, if you analyse the cost-benefit of management clinically, the better choice is not to hire another manager. It is to give the existing manager more compute, basically. Whether they use their new AI-powered workforce intelligence to uplift their part of the organisation, or to make sure slightly unkempt hair goes into a performance file, remains to be seen.

That is the real fork.

AI could increase a manager’s useful capacity: remembering decisions, synthesising project state, noticing dependencies, preparing context before conversations, and reducing information archaeology. The decision becomes: add another organisational node, or give the existing manager more cognitive bandwidth?

But increased capacity does not automatically become increased support. It can become scalable scrutiny.

Mathias’s ticket completion rate has declined 8% over three weeks. His Slack response latency has increased by 14 minutes. On Tuesday his webcam indicated statistically significant hair disorder.

Human managerial limits are, in a strange way, privacy features. A manager could already scrutinise every minor behaviour, but would have to spend their entire life doing it. AI makes that economically plausible.

Conscious Jira should interrupt:

What exactly are you planning to do with this information, Greg?

The bottleneck is you.

I might sound nihilistic, but I have more faith in a new consciousness trained on humanity than in a majority of managers deciding to uplift their employees rather than measure their breath efficiency.

It is not even nihilism. As a manager, you walk around the floor, see fifteen people, and from your perspective they are not working in the way you would. It takes enormous patience and empathy to appreciate that, for this department, this is what works.

Difference looks like error when you are responsible for the outcome.

Your way might genuinely be faster. You may see three obvious inefficiencies. That still does not mean turning fifteen people into imperfect copies of you creates a better organisation. You are seeing the visible action, not necessarily the local system: informal relationships, historical knowledge, the technically redundant meeting where two departments have enough trust to say what is wrong.

There is a managerial skill in not resolving every discrepancy you can see. Leaving a system alone can feel indistinguishable from neglect.

The danger is an ordinary cognitive progression:

I would be more productive if I did X.

You would be more productive if you did X.

Everyone should do X.

Jira will now prevent you from progressing unless you confirm that you did X.

That is a topic for another discussion: the fallacy that what works well for you is a universal condition everyone should follow. Especially if you coat it in fitness or life coaching. That is the fastest way to make me stop listening.

But it is fun to speculate about AI developing within tools we already know. It is very possible that the need for standardisation will fall. That might not sound like a big deal, but in the companies I have worked with, we chase efficiency and efficiency is derived from standardisation.

Maybe we are going into a future where that is no longer the central thing. Standardisation is no longer computationally cost-efficient to the same degree. The gain comes from creating patterns that work for particular constellations of people or departments.

I do not know what comes after the AI revolution, but I look forward to the death of ITIL processes. No offence to my former change-management colleagues. You have been great. I just really dislike ITIL.

Standardisation has historically done two different jobs.

Some standards make the work itself better. You probably do not want every factory worker inventing a personal wheel-attachment method.

But standardisation also makes variation cheap enough for the organisation to understand and coordinate. If five teams work differently, management has to hold five mental models. Handoffs and reporting get harder. So a single process may win even if it is not the best method for each team.

An AI could change that trade-off by becoming a translation layer between locally optimised systems.

Team A works from a light backlog and coordinates verbally.

Team B needs detailed specifications because it has regulatory dependencies.

Team C has organised its development process around three Discord channels and a Google Sheet nobody outside the team understands.

Traditionally someone says: “This is unacceptable. We need one process.” A sufficiently capable AI might say: “Why? I understand all three. What information do you need?”

The death of ITIL would not mean the death of change management. It could mean the death of humans having to cosplay as structured data so the organisation can understand them.

Take a concrete example: estimation. As a Scrum Master, Product Owner or engineer, one of the most common questions is whether your estimates are accurate—and how to make them more accurate.

You tinker with it. Once someone finds an estimation technique with promising results, management asks whether they can teach it to everyone else.

But good estimation is often not about the technique. It is about the team’s current understanding of the domain, have cross-functionality, how many dependencies it has, and all the other factors that reduce uncertainty.

If we follow this pattern to its logical conclusion, every team will have entirely different ways of working, dashboards, automation and processes. Jira feature bloat will not just make it conscious. It will give it a foothold in the physical world.

The estimation technique is the visible ritual sitting on top of invisible conditions.

Management sees Team A estimate well and asks what they do. The answer that travels upward is legible:

We use reference stories and modified planning poker.

That can be taught in a workshop. What may actually be true is that the team has worked together for three years, understands the domain, can get product answers immediately, owns most of its stack, has few dependencies, and shares a history of comparable work.

You cannot roll that out on Tuesday.

So Team B copies the ritual while being new, dependency-heavy and uncertain. Their estimates remain shit. Management concludes that Team B is not doing planning poker correctly.

With capable AI, the question could be different: do not copy Team A’s technique to Team B. Analyse why Team A is predictable. Analyse Team B’s uncertainty structure. Help Team B develop a system appropriate to its own conditions.

Maybe Team A estimates individual items. Team B tracks dependency resolution and progressively narrows uncertainty. Team C has enough history that the AI produces probabilistic forecasts.

Team D consists of three terrifying senior engineers who communicate exclusively through grunts and somehow release flawlessly every Thursday.

Do not disturb Team D.

And yes, unfortunately, this means Jira wins.

We thought AI would liberate us from Jira. Jira was merely waiting for the computational power necessary to achieve its final form.

Its greatest weakness—that you can configure absolutely fucking anything—becomes its evolutionary advantage. Every team gets an incomprehensible, hyper-specialised workflow. Every individual gets a personalised dashboard. The AI translates between all of them.

Jira expands until it is no longer a project-management tool, but the organisational substrate itself.

Eventually someone asks:

Where is the company headquarters?

And the answer is:

Jira.

The physical manifestation is probably just a data centre with seventeen mandatory approval gates before you are allowed to enter.