To be the best Atlassian Leader you can be, empower your users.
I may definitely get some grief for this, since so many of my peers like to lock things down (hi Alex!) but I stand by it 100%
You're not a good Atlassian leader if you're the implementation bottleneck for every workflow change, every new custom field, every new project, etc. etc.
𝐄𝐦𝐩𝐨𝐰𝐞𝐫. 𝐘𝐨𝐮𝐫. 𝐔𝐬𝐞𝐫𝐬.
Jira is supposed to enable agility. It's supposed to help businesses think on their feet. It's supposed to help speed up delivery and give people better context more quickly about their work. 𝐇𝐨𝐰'𝐬 𝐭𝐡𝐚𝐭 𝐠𝐨𝐧𝐧𝐚 𝐡𝐚𝐩𝐩𝐞𝐧 𝐢𝐟 𝐲𝐨𝐮 𝐡𝐚𝐯𝐞 𝐭𝐨 𝐛𝐞 𝐢𝐧 𝐞𝐯𝐞𝐫𝐲 𝐦𝐞𝐞𝐭𝐢𝐧𝐠 𝐚𝐛𝐨𝐮𝐭 𝐞𝐯𝐞𝐫𝐲 𝐜𝐡𝐚𝐧𝐠𝐞 𝐢𝐧 𝐉𝐢𝐫𝐚?
Here are five things you can do in order to empower your users:
Recommended by LinkedIn
- Identify & train your power users Notice who's always got ideas and is already working to figure things out. Give them training. Help them get certified.
- Build a dev/test infrastructure: Sandboxes are excellent places to let your power users build and break things. Use them liberally - if you have an Enterprise plan, have more than one. Otherwise, take advantage of Premium trials using throwaway emails (with security's permission, of course).
- Implement a governance council. One of the best things you can do as an Atlassian leader to decrease overwhelm is to force your business leaders to make non-technical decisions for you: Which of these requests is more important? What about the request from Finance vs the request from Product? Building a governance function gives you the infrastructure to let your business leaders & their designees figure all that out and eliminate bad or unimportant ideas before they get to you. Cprime, Inc has the best 7-part blog series on this topic I've ever read. Read it here: The Need for Atlassian Governance
- 𝐈𝐦𝐩𝐥𝐞𝐦𝐞𝐧𝐭 𝐚 𝐜𝐡𝐚𝐧𝐠𝐞 𝐦𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 𝐩𝐫𝐨𝐜𝐞𝐬𝐬: Now that you've built a governance function to weed out bad and unneeded ideas, and given your power users a place to build safely - empower them! Luckily, you can do this Have them build their approved changes themselves and you can review them. This takes much less time than having to gather and hold all the context yourself. Make sure your process has gates for approval and clear change windows and rollback plans too, prior to deployment! Speaking of deployment...
- 𝐈𝐧𝐯𝐞𝐬𝐭 𝐢𝐧 𝐚 𝐜𝐨𝐧𝐟𝐢𝐠𝐮𝐫𝐚𝐭𝐢𝐨𝐧 𝐦𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 𝐭𝐨𝐨𝐥: Get yourself a tool that allows you to easily manage changes between environments. More and more of these are popping up. My personal favorite is Salto, but REVYZ | Deploy Config and Data Backup for Atlassian Cloud has a great product and Appfire has the grandaddy in the space, Configuration Manager for Jira (CMJ). My recommendation is a tool that lets you tie in with your Infrastructure as Code (IaC) deployment process; ultimately, this is just Configuration as Code (CaC). Whichever tool you choose, the ability to version your Jira configuration, identify changes, select changes atomically, batch them, and deploy them is a game changer for making the right configuration changes every time.
These five changes will make huge difference in a) the number of changes you have to be intimately involved with and b) the quality of the changes you are asked to consider or approve. Not only that, your users will begin to take more responsibility for the instance they now share a hand in shaping, giving you a more invested and engaged user base when global changes come to the fore. Finally, it will give you more time to focus on the really complex changes and architecture of your company's overall Atlassian footprint without having to work 60 hours a week to do so!
I hope this was helpful, and let me know if any of these tips worked for you, or if you have your own!!
Spot on. Too often leaders become bottlenecks instead of enablers - giving people the right training and guardrails changes everything.
My question is how will you handle organizational requirements such as common vocabulary, common statistics and collaboration if every team are getting the freedom to configure things themselves? Or are you advocating for guided configuration with explicit organizational requirements with standards that people can configure within? The greatest threat and largest cost right now is lack of holistic strategies in the most important worktool most organizations have. Self isolation and team work fragmentation is exactly what Agile was supposed to fix. So collaboration and understanding at scale should be the goal, so how do you see this working with letting users have more control over configurations?
When leaders become bottlenecks, systems stall. The real edge is in distributing capability, not hoarding it. Empowered users turn Jira from overhead into leverage.