Comment by ivan_gammel
7 hours ago
A dysfunctional organization will project its failures to everything it touches. I personally have not seen such mess, likely because working in regulated industries means there‘s usually some SOP or work instruction that is regularly updated, so the setup is driven by the compliance process. Nowadays, I opt in for Atlassian because it works fine out of the box, I avoid heavy customization (which would mean tool lock-in), and Claude can move the tickets itself anyway - no scripting required.
“ I personally have not seen such mess, likely because working in regulated industries means there‘s usually some SOP or work instruction that is regularly updated, so the setup is driven by the compliance process”
I work in medical devices and our Jira is a mess too. Seems a lot of people try to solve process problems by customizing Jira.
„Every organization thinks that they are unique, yet they all are doing the same thing“ (a quote I heard last time from an SAP consultant, which is probably a common knowledge or some named law).
This is the funniest thing about customization of enterprise products. They spent hundreds of years on user research and product development, so chances are high that their standard solution is sufficient for your problem, and you don‘t need anything else. Yet too many people are tripping on the hard problem of enterprise products: the custom fields, which they hardly even need.
I find the problem is that engineering wants one work flow, product wants another, another department wants theirs, and so on.
As a CTO I have declared that Jira is owned by engineering and it is our developers’ process.
Sounds… political. You have cross-functional teams interfacing via a tool. It would be reasonable to co-design this interface, so that all user goals are taken into account. When engineering owns the tool, do they approach the configuration of JIRA the same way as they build the product?