Some pretty old and clueful people sit in these channels. Often they just watch the questions scroll by, but sometimes one of the Great Old Ones stirs in their slumber and raises to the surface, stretching tentacles and grabbing a question or a support case that looks interesting or weird.
They love their Jira, because Jira actually quantifies support, you know. It makes tracking KPIs so much easier, and then we can see if we managed to fulfill our critical TTR OKR for Q423 or not, instantly.
Unfortunately, the company does not earn money with bringing down the TTR OKR for support in any quarter at all.
Moving the support from Slack to Jira has turned a public interactive performance and discussion of operations and operational problems into a set of highly permissioned 1:1 interactions and carefully tracked escalations.
They have carefully assigned priorities and have tracked resolution times.
The Great Old Ones are blindsided now, because no one, not even they with their unnatural ancient power beyond what is allowed for mere mortals, can read Jira horizontally across all tickets.
And if they did, and rose and grabbed a ticket, maybe that ticket is resolved, but all the others would not have seen this spectacle of noneuclidic debugging and knowledge about systems from before the dawn of time, nor would they have been able to learn from this.
Probably for good, because people have been known to go insane from just reading the deploy scripts that drive these systems. And let's not even speak about the abominations that these C++ JNI methods actually hold. As a mere Java coder you will never know, and you should be thankful for that and every second of your life that you do not know about this.
In Slack questions often triggered +1's. Somebody asks about a problem, and others would chime in "That was me!", "I am having the same problem, it's company wide" or "We know this, and for us this workaround is helpful".
Moving support from Slack to Jira cut that off.
Is that bad?
No, this was not a mature process, it was individual heroics, a 0 or 1 on the process maturity scale.
These days, the ticket correlation process corp set up would find the same correlations, reliably and with a maturity of 5 (quantifiably tracked and continuously improved). Often only 4-8 weeks later the same information is available as before.
And on top, it is now orderly documented and traceable as a KPI instead of happening coincidentally when the problem was current.
@isotopp To be fair, Slack is a terrible tool for tracking long-running and very complex support incidents.
Or finding them again in the future.
Or referencing earlier parts of the information clearly.
Or referencing them in changelogs.
Chat is great and Jira sucks, but not everything should be in chats.
Collaborate via chat by all means, but the information must be in a (searchable and persistent) tracker.
@isotopp "Move it all to Slack" is a pattern I've seen when some companies try to go "more agile" or "adopt a start-up style", so consider my comment a bit of a PTSD shout out :)
@guus Everything needs to be a graphic! Reading text and spreadsheets is evil!
Thankfully that hasn't happened to me quite yet.
(I don't mind it for whiteboarding etc, but ... advanced search and verbalizing the outcomes, a necessary step for converting to code, seems hard.)
Yeah, I tried Miro for schema design and found that writing SQLAlchemy sample code and then have some tool reversing the foreign key relationships into a diagram is way faster, easier and produces less flawed results.
@isotopp And then combine that with a first level that is more interested in closing tickets then solving them. And non-portability of tickets between different departments.
@isotopp
That is what the Atlassians invented Confluence for, so the elder can pour tgeir wisdom into manicured tomes of wisdom that immediately enlighten all - in countable, billable bytes, of course…
Add comment