E12 – Ensnare Your Admins

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | RSS

In This Episode

In this episode, I share how I made my Jira project and Confluence space admins part of my team.

Products

This episode focuses on the following products:

• Jira
• Confluence

Episode Credits

This episode is hosted, produced, and music by Mark W.

Disclaimer

All thoughts, comments, tips, and best practices shared by the host and or guests of the Admins of Atlassian Podcast do not reflect the views of Atlassian nor do they replace procedures and steps officially provided in the Atlassian product documentation.

Transcript

Intro

What exactly does ensnare your admins mean?

When you are small, there is a level of support that can be done by you. I know every situation varies, but you may typically start out with creating a few JIRA projects or Confluence spaces. You’ll take some support requests when the unexpected happens.  But overall, you are able to manage the level of work that needs to be done.

As you grow, or even if you’re small, the activity of your instance increases, so does the requests for customizations and support requests from your users. When upgrades happen you find that you now have more to test. You’ve added apps or macros and they are in portions of the app you don’t use. You tell yourself, I don’t really need to test all of these projects. I don’t really need to check all of these spaces. Maybe you do, or maybe you don’t.

But I needed help. When it was just myself and another administrating the app, we wished for more eyes. And so, we ensnared our admins.

For JIRA and Confluence, you have a concept of Administrators. Or for accuracy, you have JIRA project administrators and Confluence Space administrators.  You, as the supreme administrator, have created a JIRA project or a Confluence space and you’ve bestowed these chosen few to be the administrators of their respective space or project. In JIRA, this lets them manage the project roles, components, versions, and certain agile features under JIRA Software. For Confluence, they can manage the space permissions, look and feel, and more.

These admins could also have a closer view of the work and the teams that are using JIRA and Confluence. So, why not bring them to your side?  Here is what I’ve put forth when managing Confluence and JIRA:

Administrator Requirements

First, admins knew what they were signing up for. How? I told them! When I would receive a request for a JIRA project or Confluence space, I would always request a backup admin and I would then inform them that as administrator, they are now part of the Atlassian team. They were now an Admin of Atlassian. Right? OK, I had to say that.

So, what did they do? What were the requirements?

Training

For Confluence, I did not roll this requirement out, but it was always on my list of things to do. I found with Confluence that many who were space administrators are power users already. For JIRA however, administrators were required to go through training. Yes. I had recorded a demo of all the administrator functions in JIRA detailing what an admin could and could not do. I detailed how components worked, how versions worked, roles, and shared tips and best practices. The recording was then wrapped into a section by section training video with a 10 question test at the end.

Seriously.

I wanted the project admins to be the first line of defense for user questions. For starters, they were already a lead person on their team or someone that their fellow co-workers went to. Often, they managed any customization requests such as workflow changes or custom fields, and they just knew their team’s process. So when something happened or didn’t look right, the users would go to their project or space admin and if it was something that they couldn’t figure out, that admin would then come to me. Therefore, having the project administrator trained helped immensely.

Upgrades & Testing

As my instances grew and more plugins were added as well as customization whether it was HTML to a Confluence Space, or custom workflows and scripts in JIRA, it became increasingly difficult to test.

What I mean is that at some point with over 100 spaces or over 100 projects, I could not reach every corner and function of the customization to ensure it worked. And if the team members performing that upgrade, they may not be intimately aware of what the customization is supposed to do. Why?  Well, I will dive into that in a future episode.

When it came to upgrades, the Administrators were responsible to test their space or project and let me know if anything was out of order and then sign-off once their testing was completed while I tested the core functionality and other integration points.  Administrators would then post questions or problems they found on a Confluence release notes page that I built. Most were usage questions and others were related to plugins or a bug that was encountered.

What this did was give me more eyes in testing and upgrades. It allowed the Administrators to get a first look at the next version of the application. They could then confirm for themselves if a reported bug was resolved or not. And with having a hands-on experience with the new features and a new version of the app, they could better prepare their team for what was changing. Overall, it was a great way to keep our community of users involved in the process.  Another way to do that was through evaluations.

Evaluations

One of the great things about the Atlassian products is the ability to extend the functionality. I talked about plugin evaluations and how I evaluated them in previous episodes though I wasn’t the only one to do so. When we received requests for plugins or customizations, we would place this on a lower platform to test. After my team evaluated the plugin and invited the requester to evaluate the plugin or customization, we sent out the invitation to all of our Administrators and invited them to test the plugin or customization as well and provide their feedback.

As mentioned, doing this made our users feel involved and take ownership of the platform. Another reason for this was that just because 1 person requested a plugin for customization, didn’t mean that others didn’t have this need as well. Pulling the Administrators into this helped get their feedback and maybe more buy-in as some responded: “hey, this is exactly what I’ve been needing”.

 

Closing

So, what do you think?  Do you think this is something you could use to keep your users engaged? Do you think this is a good way to extend your base of support? I’d love to know.

Thanks for listening to this episode of Admins of Atlassian. I’m Mark Williams.  If this is your first time and you like what you hear, subscribe to the podcast in Apple Podcasts, Google Play Music, or your favorite podcast app.

Until next time