In 2012, Customers Needed Process Transformation. They Asked for a JIRA Developer

[#1]

We may now be making the same mistake with AI: buying technology before deciding how work should change

I recently reviewed project requests and recruiter emails from my own archive dating back to 2012–2015. Customers asked me to configure business processes in JIRA.

They wanted me to:

• Model how departments worked

• Design workflows

• Define responsibilities

• Improve reporting

• Support project management

• Train users

Then came the list of required skills:

Java. Spring. Hibernate. SQL. Plugin development.

The advertised role was usually:

JIRA Developer

This was strange even then.

The customer did not primarily need someone to write Java.

The customer needed someone to understand why the process was failing, decide what should be standardized, clarify ownership, remove contradictions, and only then configure JIRA.

But in 2012, that service was difficult to sell.

Customers needed process transformation.

They knew how to buy software development.

“Our workflow does not work”

This was the usual starting point.

A team would say:

“Our workflow in JIRA does not work.”

But when you looked more closely, the workflow was rarely the real problem.

The real problem was that:

• Nobody owned the process

• Two departments used the same status differently

• Managers wanted reports but had never agreed on definitions

• Approval responsibilities were unclear

• Every team believed it was a special case

• Nobody could explain what “done” meant

• People wanted transparency without changing their behaviour

JIRA had not created these problems.

JIRA had merely made them visible.

But organizational problems were translated into technical requests.

So the proposed solutions were predictable:

Add a status.
Add a field.
Add a transition.
Add a condition.
Install a plugin.

The consultant was not hired to resolve the conflict.

The consultant was hired to encode it.

Why did everyone ask for Java?

The logic was simple:

JIRA is written in Java.
We need to change JIRA.
Therefore, we need a Java developer.

Sometimes this was correct. Custom development was genuinely required.

But many “development” projects were actually about:

• Workflow design

• Permissions

• Issue types

• Screens

• Reporting structures

• Organizational responsibilities

• Approval logic

• User adoption

These are not primarily Java problems.

The most useful skills were often:

• Asking uncomfortable questions

• Detecting contradictions between stakeholders

• Separating requirements from preferences

• Recognizing unnecessary complexity

• Understanding incentives and responsibilities

• Saying no to harmful customization

But these skills were difficult to put into a procurement form.

“Java developer, 800 hours” was easy to purchase.

“Someone who will challenge our operating model before touching the configuration” was not.

There was no name for the real job

Today, the same person might be called:

• Atlassian Platform Architect

• Enterprise Solution Consultant

• Process Digitalization Manager

• Platform Owner

• Jira Service Management Consultant

• Transformation Lead

In 2012, the market mostly used three labels:

• JIRA Administrator

• JIRA Developer

• JIRA Expert

The actual role was hidden somewhere between them.

You were expected to be:

• A business analyst

• A process consultant

• A JIRA administrator

• A developer

• A trainer

• A change manager

But you were usually contracted as a technical specialist.

This caused a fundamental mismatch.

The customer selected you based on technical keywords.

Then expected you to solve problems of authority, ownership, governance, and organizational behaviour.

Customization was politically safer than transformation

Adding another field rarely threatens anyone.

Questioning why the field exists might.

Creating another approval step is easy.

Asking who should really have decision authority is not.

Building five workflows for five departments is technically possible.

Asking why those departments refuse to share one process can become politically uncomfortable.

Real process management changes more than software.

It changes:

• Who decides

• Who is accountable

• Who can see what

• How performance is measured

• Which exceptions are accepted

• Which teams must adapt

Customization allowed the organization to avoid these discussions.

Every department could keep its existing behaviour.

JIRA would be modified around it.

The system changed.

The organization did not.

And the consultant who implemented every request appeared helpful.

The consultant who asked for standardization appeared difficult.

Complexity looked more valuable

There was another problem: complexity was easier to sell.

A large implementation produced visible output:

• More workflows

• More screens

• More fields

• More plugins

• More reports

• More integrations

• More billable hours

Simplification produced:

• Fewer workflows

• Fewer fields

• Fewer exceptions

• Clearer ownership

• Lower support costs

• More consistent data

The first option looked like a major project.

The second could look like less work.

Imagine presenting the result of several weeks of consulting:

We removed 40% of the configuration and decided not to build three requested features.

That may be an excellent outcome.

But many organizations were more comfortable paying for something new than paying someone to tell them what not to build.

This created a bad incentive.

A consultant could make more money implementing complexity than preventing it.

The strange truth: customers were already buying process consulting

They simply did not call it that.

When a customer asked someone to:

• Design workflows

• Map departments

• Define issue structures

• Improve collaboration

• Build management reporting

• Harmonize working methods

• Train employees

• Implement approvals

they were already buying process management.

It was just hidden inside a JIRA project.

The customer believed the deliverable was configuration.

The real deliverable was a decision about how work should happen.

When that decision was missing, the configuration became process debt.

The workflow could be technically correct and operationally useless.

The dashboard could show accurate numbers and still measure the wrong thing.

The plugin could work perfectly and reinforce a broken process.

What changed?

Over time, the Atlassian market developed better language.

We learned to distinguish between:

• Administration

• Development

• Process consulting

• Solution architecture

• ITSM implementation

• Platform engineering

• Governance

• Product ownership

• Migration

• Organizational transformation

Customers also learned—often through expensive experience—that a functioning JIRA instance is not necessarily a successful platform.

Today, it is more acceptable to sell:

• Discovery

• Architecture

• Standardization

• De-customization

• Governance

• Operating-model design

• Platform ownership

The work itself is not new.

Good Atlassian specialists were already doing it in 2012.

What changed was the market’s ability to recognize and purchase it.

Are we repeating the same mistake with AI?

I think we are.

In 2012, companies wanted to implement JIRA before deciding how work should flow.

Today, many companies want to implement AI before deciding how work should change.

The sequence is familiar:

1. Buy the technology

2. Add it to the existing process

3. Automate the existing behaviour

4. Avoid questioning the organization

But AI does not repair a weak operating model.

It accelerates it.

If responsibilities are unclear, AI creates unclear decisions faster.

If the process produces bad data, AI consumes bad data at scale.

If nobody owns the outcome, an AI assistant does not create ownership.

If a workflow is unnecessary, automating it only makes the waste more efficient.

The lesson from early JIRA projects is not “do less technology.”

It is:

Do not use technology to avoid organizational decisions.

Before configuring JIRA—or deploying AI—ask:

• What outcome are we trying to achieve?

• Who owns it?

• Which decisions must the process support?

• What information is genuinely needed?

• What can be standardized?

• What should be removed?

• Which behaviour will the system encourage?

• Where should the technology stop?

In 2012, customers needed process transformation.

They asked for a JIRA developer.

In 2026, customers may need a new operating model.

They are asking for AI agents.