|
As a Company User Group (CUG) leader, you’re not just organizing meetings - you’re shaping how Atlassian tools and practices spread, mature, and stick inside your organization.
A clear, lightweight CUG charter is one of the most powerful tools you can use to align stakeholders, set expectations, and measure impact over time.
Think of your charter as the “source of truth” for why your CUG exists, who it serves, and how you’ll know it’s working. It doesn’t need to be long or formal, but it does need to be intentional.
Below are five practical tips to help you define your CUG’s purpose, scope, and success in a way that’s clear, actionable, and easy to socialize.
1. Start with a sharp, one-sentence purpose statement
Your purpose statement should answer: “Why does this CUG exist?” in one or two sentences - max. If someone only reads this line, they should immediately understand the value of your group.
Examples:
-
“The Atlassian CUG exists to help teams across [Company] collaborate better by sharing best practices, templates, and real-world use cases for Jira and Confluence.”
-
“Our CUG brings together champions and practitioners to improve how [Company] plans, tracks, and delivers work using Atlassian tools.”
A sharp purpose statement:
-
Keeps your activities focused
-
Makes it easier to pitch the CUG to leaders and new members
-
Helps you say “no” to requests that don’t fit your mission
Write a draft, then refine it until it’s simple enough that anyone in your company could repeat it accurately.
2. Clearly define your scope: who you serve and what you cover
Scope is where many CUGs drift over time. Your charter should spell out who the CUG is for and what topics or tools it focuses on - and just as importantly, what’s out of scope.
Consider defining:
-
Audience:
-
Who is this for? (e.g., admins, project leads, team members, executives, or a mix)
-
Is it open to everyone, or targeted to specific roles/teams?
-
Tools & topics:
-
Which Atlassian products are in scope? (e.g., Jira Software, Jira Service Management, Confluence, Trello, Bitbucket, Compass, etc.)
-
Are you focused on configuration, governance, best practices, or day-to-day usage?
-
Boundaries:
-
What will the CUG not do? (e.g., not a replacement for official support, not a formal training program, not a decision-making body for tooling purchases)
A clear scope helps:
-
Set expectations with members and leadership
-
Avoid becoming a catch-all for every tooling problem
-
Keep your sessions relevant and valuable to the right people
3. Define what “success” looks like with 3–5 simple measures
Your charter should make it obvious how you’ll know if the CUG is working. You don’t need complex KPIs - just 3–5 simple, trackable indicators that align with your purpose.
Examples of success measures:
-
Engagement & reach
-
Value & impact
-
Member feedback scores (e.g., “Was this session valuable?” on a 1–5 scale)
-
Number of shared templates, playbooks, or best practices adopted by teams
-
Enablement & maturity
-
Increase in self-service usage (e.g., fewer basic “how do I…?” tickets)
-
Number of champions or power users identified and activated
In your charter, write these as clear statements, such as:
These measures give you:
-
A way to show progress to leadership
-
A compass for deciding what to prioritize
-
A baseline to improve from over time
4. Document roles, responsibilities, and ways to contribute
A CUG is stronger when it’s not dependent on a single person. Your charter should outline who does what and how others can get involved, even if your group is still small.
Consider including:
-
Core roles
-
CUG Lead / Organizer – owns the charter, agenda, and communication
-
Co-leads / Backup – supports planning, hosts when the lead is unavailable
-
Tool Admin / SME – provides deeper technical context when needed
-
Member expectations
-
How often you expect members to attend
-
How they can contribute (e.g., share use cases, present demos, suggest topics)
-
Contribution pathways
By documenting roles and contribution paths, you:
-
Reduce risk if someone changes roles or leaves
-
Make it easier for others to step up and help
-
Signal that the CUG is a shared community, not a one-person show
5. Set a simple operating rhythm and review cadence
Your charter should also describe how the CUG runs and how often you’ll revisit the charter itself. This keeps your group predictable, sustainable, and adaptable as your company evolves.
Include details like:
-
Cadence & format
-
How often you meet (e.g., monthly, bi-monthly, quarterly)
-
Typical session formats (e.g., demos, show-and-tell, office hours, panels, AMAs)
-
Communication channels
-
Where members can find updates (e.g., Slack channel, Confluence space, email list)
-
Where you store recordings, slides, and resources
-
Charter review
-
How often you’ll review and update the charter (e.g., every 6 or 12 months)
-
Who needs to be involved in approving changes (e.g., CUG lead + sponsor)
A clear operating rhythm:
-
Makes it easier for people to plan and attend
-
Helps you avoid burnout by setting realistic expectations
-
Ensures your charter stays relevant as tools, teams, and priorities change
Bringing it all together
A CUG charter doesn’t need to be long or formal - but it does need to be intentional. By clearly defining your purpose, scope, and success measures, and pairing them with simple roles and an operating rhythm, you create a foundation that:
-
Aligns stakeholders and members
-
Keeps your efforts focused and sustainable
-
Makes it easier to demonstrate value to leadership
If you already have a CUG running, treat this as a chance to retro your group: draft a charter based on what’s working today, then refine it with feedback from your members and sponsors.
Helpful Resources
Here are core resources you can lean on as you build and refine your CUG charter and overall program:
-
Atlassian Community – Connect with other leaders, ask questions, and see how others run their groups
-
Atlassian University – Training and learning paths you can reference or promote through your CUG
-
Atlassian Team Playbook – Plays you can adapt for CUG sessions (e.g., retros, health monitors, working agreements)
|
2 comments