“Ticket Monkey”

tl; dr – I hypothesize the physical and emotional distance of ticketing systems reduces job satisfaction and propose solutions.

Bear with me.

I remember when I was a kid I knew how to code. I didn’t get as good grades as I could have, I didn’t shine in a few other ways, but despite this I knew I could do something special. I could build interesting things and I could fix problems.

When it came to my first job I felt the same way. At the time I’d say I was still a bit “rough around the edges” but I could fix problems, sometimes hard ones, and that made me useful. It felt great to be needed using the one way I knew I was good at. There was nothing like somebody walking over to my desk to tell me about a problem that was making their lives hard, and to be able to fix it for them.

Pretty soon though a number of more senior engineers started speaking up. “We can’t have interruptions like this. We need to be more structured. We need to track this work. We need to put to asks in JIRA.” I had the same reaction a lot of people do, which was “Why do we need to track this? Do we not trust everybody is working to the best of their ability?”. I got the usual answers about the importance of estimation, planning, etc, and didn’t entirely understand, but accepted.

Years later, senior myself, I would insist – every code change must have an associated ticket. That isn’t to say I’m some kind of agile evangelist, but I certainly found ticketing systems indispensable, even for the smallest of teams. Somewhere along the way I had forgotten that I had ever felt otherwise.

Next role I became the main SRE for a chaotic startup. Some people would hate it, but I loved it. The buzz and thrill and of a war-room was incomparable to the transactional feature development that would eventually lead to an A/B release that would then possibly lead to a small % improvement in a metric. I loved fixing things for other engineers who I saw in person, who were happy and impressed that I would fix their issue and improved the whole system to make the issue impossible in the future.

What I loved wasn’t inherent to being an SRE itself. Though a high-stakes role, it can also be as isolating as any role. It can be waking up to an alarm at night to login in by oneself and fix an issue, file a ticket, and have nobody notice.

What I loved was face-to-face interaction and a shared emotional narrative.

From another angle – when I go to whole foods and watch the cashier scan my overpriced items, I wonder what they think. Though small talk with strangers is far from a strength for me, I struggle anyways to connect in whatever small way I can. I don’t think I could force a joke and trust the timing to line up with the variable checkout time. I try to be nice without being stiffly polite. It may mean bagging my own groceries, or avoiding the instinct to stare at my phone. I can’t even say for sure that cashiers notice or like it. I simply presume that if I were in their shoes I wouldn’t want to feel like a machine.

The Answer

Well first, the question: How do we reconcile our desire to feel individually noticed and human with the business needs of standardization? I think this question is the most important piece of this article. I’ll make a proposal or two, to get the ball rolling, but the topic is wide-open.

  • What if tickets are filed normally through jira, but then the filer must also come over to the desk of the person operating on the ticket and explain the issue face-to-face?
  • What if tickets are described in a way that stresses the emotional importance to the user of the feature?
  • What if end-user satisfaction and wishes, as captured by PMs who communicate with users, was shared with engineers?

How would you achieve it?

One thought on ““Ticket Monkey”

  1. I run Jira for a large company and see a lot of different opinions about it. Some of them are about the tool, some are more about what is discussed here.

    1. We have a clean escalation procedure where Jira issues are not assigned to people without discussing it with them, in some way. This avoids that nasty feeling of having work dumped on you.

    2. A Priority field is often a stand-in for this information. It is really useful to know how someone feels about an issue before working on it. “How do you feel about this problem?” is one of the things I’ll be discussing at JiraCon in October

    3. PMs or others can be helpful in creating requests for change that are better than the original requestor might have created. Depends on the relationship between the requestor and PM

Leave a Reply to Matt Doar Cancel reply

Your email address will not be published. Required fields are marked *