4 ms·

Hmm, I communicated wrongly then. Because the separate system for issues is for a different team and a different purpose and no, it's definitely not a solution

by Almad 6y ago

Hmm, I communicated wrongly then. Because the separate system for issues is for a different team and a different purpose and no, it's definitely not a solution to the problem, but rather a prerequisite for the outlined system to have a chance at working at all.

jpswade 6y ago
You described it as a “separate system for handling questions for the development team”. How do you propose that queue is prioritised and consumed by the development team?
- Almad 6y ago
  In both companies I've been using that, it was a very simple RT/JIRA-SD-style system: "open a subject/text ticket, clock starts ticking, on call engineer gets a non-wake-up memo and will reply with high priority during work hours" and ticket will get closed ASAP and we do achieve inbox 0 regularly. Yes, there are obvious issues and it requires two things to work: 1) If you actually have no clue about the product, you are respectfully told to fuck off to normal user support channel 2) If you keep misusing this for user support / slack channel, you get your access revoked. ...which are hard sells in large companies, of course—on the other hand, in BigCo I got success in getting an engineering headcount to accommodate that.