I showed the CTO and CEO ZenHub and we're off to the races.
One axis is number of people actively using the tracker for a single project — I personally think that threshold is around 50 people^1. Another is workflow complexity — very few tools are as capable of mapping business processes to software as JIRA^2.
1. Careful, there's another threshold at which JIRA becomes painfully slow. At that point you either move to something that's less adequate in nearly-every way but scales or you start splitting JIRA instances by department or project.
2. Careful here as well! Poorly created JIRA workflows are probably _the_ #1 reason people hate using it. Users learn a highly customized JIRA workflow and think it's absolutely bonkers that Atlassian did this to them, when really it's their company's customizations that are causing the pain.
It’s probably inevitable but a policy requiring strong justification for and regular review of any “aftermarket” changes might slow down or reverse the descent. The closer it is to vanilla the easier it is for (almost) everyone. Managers and workflow czars (nice one btw) of course would be inconvenienced but they should be comfortable making really strong justifications for making the lives of developers harder just to make their reporting smoother.
I attended a talk by a Netflix employee where they talked about a sort of organizational immune system to aggressively prune bureaucracy and policy by forcing it’s existence to be regularly justified. It helped me connect the dots and realize that allowing heavy customization was as much a poison as it was a boon.