5 Questions in the Atlassian Universe with Matthew Sinclair
Maria Reisinger·2026-07-29·7 min read
About Matthew
Matthew Sinclair Enterprise Atlassian Administrator, Aristocrat Mount Vernon, Washington, USA
"Governance is more than safety. It's bringing order out of chaos."
Matthew manages Atlassian products across a large enterprise environment, with a strong focus on governance, Jira administration, Jira Service Management, automation and change management. His background in incident response and infrastructure operations gives him a practical perspective on balancing flexibility with long term maintainability.
Areas of Expertise
-
Enterprise Jira Administration
-
Jira Service Management
-
Atlassian Governance
-
Change Management
-
Automation
-
Incident Management
Question 1
You manage Atlassian products across a large multi-site organization. What does governance actually mean in your day to day work, beyond the textbook definition?
Governance prevents situations where you have 10 Statuses that mean the same thing. 20 Custom Fields that all mean the same thing - but differently named. I exaggerate - but even 5 is 1 too many.
While some may shrug at what I'm saying - imagine if you have 3000 spaces of that 3000 you have 100 over here using the Status "Done" and another 200 using the Status "Finished" - and 1000 using "Resolved".
Which one is the correct one?
Another one - is "Canceled" vs "Cancelled" - both are spelled correctly - but you have a split decision debate on which one is correct.
Governance is more than safety - it's bringing order out of chaos.
You will find dev engineers/PMOs/tech groups all debating which is which - but sometimes it's a matter of getting everyone to agree on one thing and keeping that line.
To an Atlassian Admin (Space/Jira/Site/Org level) - it's a matter of holding the line and maintaining the standard - not compromising - not making one more status - one more field - just because someone said they needed it. You have to dig deep - and maintain best practices as much as possible.
A good example is Jira Service Management - someone asked for Backlog - there's no such thing as "Backlog" of any kind or mechanism in the Application - you can make one - but it's entirely pointless. Jira? Yes. Maybe Jira Product Discovery (but since JPD is Team Managed, not much you can do there).
Governance/Standards requires everyone working together and sometimes - learning to say "no."
Question 2
You've pointed out that archiving in Atlassian doesn't really do what people think it does. What do admins most often get wrong about cleanup, archiving and deletion at scale?
Communication
Sometimes not communicating what/where/why leads to confusion - and most users don't understand how things work. Helps to illuminate the situation - to educate what goes on in the background.
Justification
Why are we choosing to archive over deletion? Is this a matter of data retention policies? Solutions should be sought. Many Atlassian Admins may not be aware of the weakness of Archiving. Marketplace Apps are tempting - but a good open discussion would help discuss options - even we are puzzled over this. But having 3000 projects in archive occupying resources - tying up fields/schemes - isn't helping.
Method
If I had a say - I'd mandate archiving should result in deletion after so many days - we need to know why they need to keep it. Better yet - why archive the space? Perhaps it should be a mass export and silo the issues off - then keep the same space live in production - issue count is a problem - or just simply let the issues stay in system resolved out. I don't have a perfect answer - as much as I'm inclined to say "kill it with fire" - some policies may not allow this - requires a long discussion with more experienced minds than mine. One thing's for sure - the backup/archive solution we have native to Atlassian - doesn't work. Exporting issues only retains issue data - not configuration. So while we could dump the issues - some things may get lost.
Mistakes
As I said the major weakness of archiving is they tie schemes up. You will get silent positive hits on JQL if something is in archive (although I think Atlassian changed that) - more and more JQL shows nothing - but that doesn't mean there's no data. Schemes/Fields/Statuses all consume guardrail counts - even if it's not live in production. You cannot move/change/alter spaces in archive - you have to unarchive to query/scan/check/alter. At least with issue archiving you can still see the data if you know where it is. Although I may be a little off on archived spaces - things keep changing and it's hard to keep track of it all - All I can say for sure is it's very painful to deal with so many spaces. Cleanest cleanup is to delete it - but stakeholders may not like that.
Question 3
What's the hardest part about keeping visibility and control when an environment has grown over many years?
Change Management - consistently following processes - logging changes - my mentor pushed hard on Confluence logging - but the problem is tickets are easier to log - but tickets are also harder to search/scan for. Something I need to look into exploiting Rovo for in the future. There's also the process of approval of changes - level of change warranting an approval - which things require sandbox test vs production change? That and many admins are not trained (not necessarily credentialed (ACP)) - they are learning as they go. Many bad habits are innocent errors. I was lucky - but I know I can do so much better.
Question 4
When a security review or audit asks "who changed this, when, and why", how well can a typical enterprise environment answer that, and where does it fall short?
Change Management - without it - it's hard. The Audit logs help (Jira Admin/Org Admin levels) but it's like reading tea leaves. Planning to exploit Rovo to read that more effectively if possible. We've had situations where a change was made without oversight - nearly broke production - lot of it is lack of experience - worse - lack of communication due to pressure or other.
Change Management is annoyance/tedium/slow down - but necessary to preventing Major Incidents.
Question 5
What's one lesson you wish every Jira admin learned much earlier in their career?
Network - network with as many Atlassian Admins as you can - and make sure you have some Security/PMO/Data Science/Engineering minded folks in the room - that provide the why beyond the Atlassian sphere.
The joke I like to push is this - "Atlassian's greatest feature for their products is absolute customization. Atlassian's greatest failure for their products is the absolute customization." We laugh - but we cry.
Every Atlassian admin needs to ask these questions - "We can do that - but should we do that? And 6 Months later - is this a good idea? 1 Year later? 5 Years later? - 10 Projects later? 200 Projects later? What are the consequences of this change?"
It's too easy to "push the button" - and I like to always tell myself and peers - there's no undo button - even if there is - working with that in ones mind keeps you from making very big mistakes.
And I've made some - thankfully they tend to be very few and far between.
Five lessons from Matthew Sinclair
-
Governance creates consistency.
-
Every configuration has long-term consequences.
-
Archiving isn't cleanup.
-
Change management matters.
-
Think five years ahead.
Thank You
Our sincere thanks to Matthew Sinclair for taking the time to share his experience, practical insights and honest perspective on enterprise Jira governance.
Your willingness to contribute to this interview series helps the wider Atlassian community learn from real-world challenges and encourages meaningful conversations about governance, change management and sustainable administration.
We truly appreciate your time and your openness.
About this series
5 Questions in the Atlassian Universe is an interview series by MetaFrazo featuring experienced practitioners from across the Atlassian ecosystem.
Each conversation explores practical lessons, real challenges and proven approaches to managing Atlassian products at scale.
Because the best ideas don't come from tools alone. They come from the people who use them every day.
About MetaFrazo
MetaFrazo helps organizations understand what is changing, what matters and where operational risks are emerging inside Jira.
By transforming Jira metadata into operational intelligence, teams gain the visibility needed to improve governance, reduce configuration drift and make better decisions without exporting sensitive business data.
www.metafrazo.cloud · Available on the Atlassian Marketplace
See you in the next edition of 5 Questions in the Atlassian Universe.
Rate this post
Related articles
The AI Shift in Jira: We May Be Asking the Wrong Question
AI is reshaping the Atlassian ecosystem quickly, and every new announcement raises the same worry about whether AI will replace Marketplace apps. This article argues that the more useful question is which problems AI can genuinely solve and which ones still need specialized products. AI is becoming the interface and it makes automation far easier, yet automation only answers what should happen next, while intelligence answers what is actually happening across hundreds of projects. Because operational risk builds up from many small, reasonable changes over time, the lasting advantage belongs to products that give organizations visibility into what their configuration is quietly doing, not just tools that perform individual tasks faster.
2026-08-04
Why Jira Governance Fails Long Before Anyone Notices
One team calls it "Done." Another "Closed." A third "Resolved." Each choice is perfectly reasonable. But ask across 200 projects how much work is actually complete — and suddenly there's no reliable answer. That's not a Jira problem. It's a visibility problem. In my latest article I argue that enterprise Jira governance rarely fails because of bad rules. It fails quietly — through hundreds of well-intentioned decisions that slowly drift apart until no one can see the whole picture anymore. The shift that matters isn't stricter policies. It's moving from "What changed today?" to "What has been changing over the past six months?" — from reacting to symptoms to spotting drift before it breaks something. I break it into three stages every Jira team can locate itself in: reactive → aware → proactive.
2026-08-03
From Event to Insight: How MetaFrazo Turns Every Jira Action Into Operational Intelligence
Your teams generate thousands of signals inside Jira every day, and most of them are never used. This walkthrough follows the MetaFrazo pipeline step by step, from the first click on any device to real-time operational intelligence on an administrator's screen.
2026-07-31