Interview With an Expert: How Chris Rainey Found His Place in the Atlassian Community
From an uncertain first-timer at the certification booth to a Champion who now helps others find their place.
“I leaned into the discomfort.”
— Chris Rainey
Chris Rainey’s first Atlassian conference almost didn’t include Chris Rainey.
He walked into Team in Vegas in 2024 as a customer, representing his employer, knowing no one. It was his first conference of any kind. His only prior experience with the community was a little time spent on the forums.
So he did what a lot of us would do. He found the safest-looking spot in the room and headed straight for it.
For Chris, that was the certification booth. In the months before the conference, he had earned every certification needed for the Atlassian Certified Expert designation at the time. The booth felt like familiar ground. Someone asked whether he had taken any certifications. He said yes, and told the story. His answer was interesting enough that he was asked, on the spot, to be interviewed about it.
He was new to all of it and well outside his comfort zone. He did the interview anyway. In his words, “I leaned into the discomfort.”
When it ended, he was asked whether he wanted to become a Community Leader, the former name for what we now call Champions. His response was honest. “What’s a Community Leader?” He said yes before he fully knew what he was agreeing to. A few months later, he onboarded as a Certification SME.
Today, Chris Rainey is an Applications Systems Analyst at a mission-driven organization, an Atlassian Community Champion, and, at the moment, a very busy admin. He’s standing up two new Jira Service Management spaces, one for each of two teams. He’s also the kind of practitioner this series exists to find, because the interesting part isn’t only what he’s built. It’s how he thinks about the work.
The problem he kept hearing about
Chris’s current project sits on a familiar fault line. His organization has teams that live in both Jira Service Management and Jira. Work arrives as a service request, and sometimes that request turns out to be development work. Someone has to move it from the service side to the development side.
There was no consistent way to do that. Chris kept hearing about it.
“It was an annoyance for teams that I continued hearing about,” he says, “so I decided to take a stab at addressing the problem.”
What he built is deliberately plain. From inside a JSM ticket, when someone spots development work, they can trigger an automation by hand. It closes the service ticket, creates a linked work item on the development side, and prompts for two things: which space the work belongs in, and what type of work it is. The item lands in a backlog, where it can be prioritized alongside everything else.
It’s an MVP, by his own description. Super basic. That was the point.
“I wanted to make sure that it’s valuable for the teams first before I continue to go down the path of making it better,” he says.
The lesson he takes from it is worth stealing. Understand the problem before you build for it.
“Rome wasn’t built in a day, and that’s true for technology as well,” he says. “Whenever you’re building anything technology focused, you have to have a very good understanding of the desired process or at least the problem that you’re trying to solve.”
He understood the problem first. The automation is creating real value now. Those two facts are related.
Before you touch anything, understand how it got this way
Ask Chris what he does when he inherits a Jira or JSM site that has grown messy over the years, and he doesn’t start with a cleanup checklist. He starts with restraint.
“Before I touch anything, I like to start by mapping out the current configuration and by understanding the biggest pain points,” he says. If anyone who remembers how the system got this way is still around, he seeks them out.
The reason isn’t politeness. It’s prevention.
“It’s easy to want to jump into Bob the Builder mode,” he says, “but first understanding what caused the state we’re in today is the best way to prevent us from ending up in the same scenario in the future.”
Only then does he pick up a tool. And the first place he goes is permissions. He evaluates the groups that exist, the access those groups have, and the permission schemes behind them. Getting that right lowers the risk of doing further harm while the cleanup is underway.
Two things he leaves alone, at least at first: workflows and automations.
“I feel like those are the two things most connected to business processes,” he says, “and touching those without context could make things significantly worse than they are.”
Underneath the method is a principle he’ll defend even when it’s inconvenient. He’s an advocate for the principle of least privilege, especially where JSM is involved. He knows it can feel like a bottleneck to users. He feels it’s worth it anyway.
“It’s a necessary evil, if you will, to protect the integrity and health of the system,” he says, and it heads off future headaches and tech debt. Then, with a grin you can hear in the text, he adds that understanding the system is no small feat. “It’s what keeps all of us admins employed.”
Building for the day he takes a vacation
Here’s a small habit that tells you how Chris treats his own work.
Every automation he builds gets the same setting switched on. Notify on error, every time a flow starts failing after it had been working. If a rule breaks, he hears about it.
That’s more discipline than most admins bring to their automations. Chris is also the first to name where it falls short.
The alerts all go to one inbox. His.
“I know the error notifications going only to my inbox isn’t a scalable approach,” he says, “especially if I want to ever take a vacation.”
So he’s working on something better. He wants those automation errors to surface as alerts inside JSM’s Operations, where they wouldn’t be his alone to manage, and where a real problem could be turned into an incident and worked properly.
It’s a quietly telling idea. Chris treats his automations the way you’d treat anything running in production. They need to be watched. They need an owner who isn’t a single point of failure. He’s pointing the service management tools at his own service.
Honest about the agents
When the subject turns to AI agents inside Jira, Chris doesn’t reach for a script.
He can see where they’ll help. His organization is leaning harder on metrics, and metrics are only as good as the work behind them.
“Those metrics are only reliable if we’re keeping our work items up to date,” he says. Keeping work current is exactly the sort of steady, unglamorous job he can imagine an agent doing well.
Then he says the part most people leave out.
“Admittedly, in my current role, it’s been really difficult to even wrap my brain around the concept of agents and where they could support processes.”
Some of the hesitation is about capability. Some of it is about people. His users have absorbed a lot of change lately, and they’re feeling it.
“There have been a lot of changes taking place and users in my organization are definitely feeling some change fatigue,” he says. “I even still have users complaining about the Jira Navigation update.”
That isn’t resistance to AI. It’s a practitioner declining to spend his users’ patience on something before he can explain what it does for them. His caution is a form of respect.
Here for the humans
Chris came back from Team ’26 in Anaheim with a phrase.
Here for the humans.
It came out of a Champion workshop led by Josh Costella, titled “The Champion Role in the Age of Rovo.” Chris describes it as deeply personal and introspective, a session about the one thing AI can’t replace: the human connection.
That connection is most of why he loves being a Champion.
“I get to connect with others who have been exactly in my shoes,” he says. He also gets to connect with people whose experience runs far deeper than his own. And then the part that closes the loop. “I, in turn, get to be that wealth of knowledge and expertise for someone else.”
The same thread runs through his day job. Working for a mission-driven organization changes what a ticket means to him.
“Every JSM ticket or Jira item that I work on has a direct line to the customers we serve,” he says. Each item is rooted in creating value for the people on the other end. That is what keeps him where he is, along with a set of core values he tries to live by: integrity, honesty, respect, and openness.
You belong
Near the end of our exchange, I asked Chris what he’d want a service-desk tech to hear, someone who wants to grow into the kind of role he has now. He didn’t offer a single answer. He offered the answers he’d needed to hear on his own way up.
Give yourself permission to not know everything, he says, because waiting until you feel fully ready holds you back. He still catches himself doing it. The move that beats it is one sentence. “I don’t know yet, but I can figure it out.”
Ask questions, and keep asking until you understand the problem and the value you’re there to create. Never assume.
And don’t let perfection get in the way. “We can’t let perfection be the enemy of progress.”
The one he means most is the simplest.
“You belong. You didn’t get here just by chance. You worked hard and you earned your place.”
Those certifications he chased were never really about the badges. They were his way of answering a quieter question. Whether he belonged in IT. Whether he belonged in this community. Whether he belonged as a Champion. He’ll tell you the imposter syndrome hasn’t vanished. It just speaks up less often, and with less authority, than it used to.
This Article is Part of a Series
We’re all subject matter experts in our own ways. And we all have something to teach others, whether we know it or not. This article is a departure from its predecessors because in this case, the expertise Chris had to share wasn’t solely about using the Atlassian Service Collection, it was about the importance of embracing the Atlassian Community.
It’s still part of an ongoing series that features real-world Atlassian professionals and their helpful insights. Chris’s insights just happen to be about something more human.
Perhaps you also have experience creating impactful solutions with the Atlassian Service Collection? If so, drop me a note. I’d love to interview you.
About the Author
Dave Rosenlund is an Atlassian Community Champion and the founder of the virtual Atlassian Community Events chapter, CSX Masters (fka ITSM/ESM Masters). In his day job, he works for Platinum Atlassian Solution Partner, Trundl.
AI tools helped research, draft, and refine this piece. The ideas, the structure, and the responsibility for what it says belong to the author. AI helped get past the blank page. The thinking is human.
Was this helpful?
Thanks!
Dave Rosenlund _Trundl_
1 comment