Calling all enterprise growth stories (We want to hear from you)!

[Brian Keough]

Howdy Enterprise Community!

Managing growth can be a challenging experience, but it’s something all organizations eventually face and should be prepared for. For some this can come in the form of organizational growth with teams growing at fast rates and across multiple geographies. For others it can come in the form of user growth, with Atlassian usage spreading to new areas of the business each day.

Regardless of what type of growth you experience, it’s important to have a strategic plan in place to scale your Atlassian tools so they are reliable, performant, and can meet your maturing enterprise needs. While most Atlassian customers share a similar growth story, their journeys are also unique. Each has its own lessons that others can learn from.

That’s why we’d love to hear from you about your growth story! What went right, went what wrong, what you’d do differently, etc. We’re hoping to start a discussion that others facing similar growth can look to for guidance.

We can't wait to hear your stories - and thank you in advance!

[Matt Doar]

I've been working with the LinkedIn Jira for about 9 years now. It's grown from under 100,000 issues to about 5 million these days. And using Jira Data Center it's really rather stable too.

Things I wish I had done differently are:

1.  Never allowed so many Jira admins to be added. At one point we had over 70. This lead to 1600 custom fields, many pretty specific to one or two projects. It's tough to clean up this kind of configuration excess

2. Establish clearer rules for which teams get Jira projects. We get about one request per day for a new Jira project, often because people thinks a new project/product/team must mean a new Jira project

3. Pushed back on teams that want to use Jira as a general purpose database. If a ticket doesn't have some kind of user interaction with it, perhaps there shouldn't be thousands of them in Jira

In hindsight there are lots of things we did do right - a different service account for each tool/service that is integrated with Jira, using Jira to track all changes to Jira, keeping local documentation up to date in our wiki.

[Danny DeGregorio (LinkedIn)]

I have been working for Linkedin on their Jira team for over a year and a half and here are some things that stick out to me:

Piggybacking off of Matt's response: 

• Creating governance as early as possible
  • One thing I've found to be very consistent about Jira is adding new things (whether that is fields, statuses, issue types, add-ons, etc) is very easy to add, the hard part is to get rid of them. Having a defined set of rules early on makes it much easier to push back on a request and helps ensure scalability. 
• Keeping things generic when you can
  • The more customization we do, the harder it becomes to upgrade each year. More testing needs to be done to verify an integration or an add on still works. This extends to naming fields. A field named something like "Date committed in Project FOO" while helpful when used in one project will most likely not be reusable by most other projects.

I'm still quite impressed with the Jira instance that I inherited. It is rather snappy and I have hardly heard a complaint about anything taking too long to load. 

[Andrew Morin]

Editing

[Dom Baldin [Adobe]]

Since taking over Adobe's Jira instance, I have watched it grow from a user base and issue count of ~6k and ~1M, to now well over 22k globally and 5.6M+, respectively. The main factors driving this growth were a combination of an executive directive for alignment/consolidation, and a dedicated team equipped with the knowledge and skills to architect and lead this key objective.

What went right

From the outset, we knew we needed to create support processes and guidelines for our team that would allow us to support a user base 3-4X larger, as well as usage policies and guardrails that would ensure application stability and satisfactory customer experience.

Things like:

• Establishing standardization of project configuration elements - issue types, custom fields, permission/notification schemes, project roles & membership
• Documentation - LOTS of documentation advertising offerings/standardizations, expected use, SLAs, how-to's, FAQs, Help guides
• Self-service tools to delegate power back to users for key operations we felt should be managed at the team level.
• Culture/mindset shift for Jira Team from doers to enablers - We teach people to fish by using every interaction as an opportunity to teach them how to use Jira (documentation is huge here). We transitioned responsibility of managing project access permissions back to Project Admins, and created tools to facilitate this collaboration.
• Restricted Jira Admin permission to the Jira Team, and only the Jira Team. No exceptions.
• Established a self-healing environment, entirely eliminating manual effort in host mgmt - no unplanned outages in over 1.5 yrs 🤙🏽
• Created collaboration channels for users to get together and help each other, interact with Jira Team, etc (Slack, Confluence, NOT email)
• Discouraged the use of Jira for alert and monitoring notifications. Established clear purpose for Jira projects and issues.
• Created a Scrum for Jira support and roadmap

What went wrong or what we'd do differently

The large majority of our growth came in the form of consolidations of other Jiras and systems from acquisitions and other. In the early days before my arrival, these consolidations/merges were mostly picking up all data and configurations from the source system and dumping it in the destination system. Big mistake. This created a ton of work in alignment down the road which is tremendously harder after the fact. Doing it over, we'd have spent the time upfront aligning and negotiating elements. This is how we handle Jira merges today.

It's been a good ride! Think I missed happy hour blabbering on here. Hope it helps!

✌🏽

[DPKJ]

Such big instances.

Can you guys share experience with various add-on, how did they scale up?