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:
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:
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:
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:
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:
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:
Buy the technology
Add it to the existing process
Automate the existing behaviour
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.
