Ticket Monkey
blog.alexrohde.com
blog.alexrohde.com
On the one hand, companies ask me to put all this work into my tickets. Fill out this field, fill out that field, link to this thing, organize it this way... etc.
On the other hand, the company puts NEAR ZERO real effort into making this experience easy and efficient.
I've seen it happen most often with companies that flip-flop between defining themselves as a "start-up" but in the same breath talk about their worldwide enterprise presence. Of course they have 500+ employees. Sometimes thousands. They like to put on their startup hat when refusing to pay money for things and they like to put on their large scale enterprise hat when instituting ticket requirement policies.
When we started down the path toward Salesforce-ification, it involved lots of bulleted feature lists. Maybe 1-2 wireframes. Then this was handed to contractors who implemented it exactly as written without an eye towards usability. Simple things like saving a ticket with some fields blank or unknown we’re not supported and made the entire ticketing process miserable.
I eventually stepped in as the voice of the “customer”, customer in this case being fellow engineers and support staff. I eventually left the company before the final implementation, but even by then no one prioritized usability and design.
Even trivial amounts of text can put people off, even when the individuals are supposedly high calibre (ie university educated/heavily interviewed)
The problem is this encourages brevity to the point of omission by the writers of tickets and then these various ticketing systems lose a big chunk of their value because no one has much of a clue what they're for afterwards!
I've seen this repeatedly at places where they want developers to track what they're doing, but they don't have any product function to populate the backlog, groom it or prioritize tasks. It's basically anarchy but the devs just document what they felt like doing. Of course developers come to resent this system because nobody wants to read their diary - everyone else wants to know how close things are to being done. But because the whole project hasn't been scoped and broken down, it's impossible to get that knowledge from a snapshot of what people have been doing.
Maybe it's just that smaller places more focused on getting stuff done in a hurry are more fun for some people.
I do find it interesting that I've noticed many product managers use ticket systems to track and reference work and changes, while programmers use version control systems to do something very similar. These two systems often link to each other via hyperlinks in ticket systems and ticket numbers in commit messages. The most coupled systems like git and Github Issues are still at arm's length to one another. Even Fossil (to the best of my knowledge) considers tickets and source commits/branches/etc to be separate entities. Maybe there's something worth looking into there that integrates the concepts more than just links and hooks.
The bigger issue IMHO is that rush of endorphins when I complete a ticket. It's more fulfilling to me when I can quantify my productivity, and tickets allow me to do that. But that combines with the idea that your work = your worth, which is completely untrue. That's the core issue that I'm still trying to work on for myself.
I don't think it's either objectively true or false, but if you find it true for yourself, then it most definitely is true. There are few things more satisfying in life than interesting work done well
Neither situation (informal issue passing via word of mouth, or a ticket system) even work close to 100%. A lot gets lost in translation. Maybe we just need less layers and more engaged engineers? People who care? Though hard to genuinely find.
- In a three-developer startup a ticketing system might very well be just needless busywork. You probably have plenty of urgent things to disprove so that you can iterate as fast as possible. Put them on a whiteboard, and make sure everyone is on the same page about what you're building every day.
- In an organisation where the tickets may live longer than someone's tenure a formal ticketing system may be necessary, if only to make sure long-term ideas are not lost or forgotten.
- In an organisation with more than four developers working on the same thing long term you probably need tickets just
- A lot of managers unfortunately don't realise how time-consuming and soul-crushingly boring it is to fill in every single field in an "advanced" ticketing system, like priority (just order things in the backlog!), severity (should be part of priority, not its own field), cost (ditto), deadline (ditto), sprint # (ditto dammit!), reported by (should be recorded automatically), and tags (who actually thinks those are accurate across the board and have the same meaning to everyone?). These orgs don't need an advanced ticketing system, but use them because they are more enterprise-y and that feels good to middle managers who care about visibility rather than productivity.
- Huge orgs which have lots of geographically distributed developers working on the same thing definitely need an advanced ticketing system, if only so different people aren't doing the same work in parallel.
And the only thing less effective than an organisation with a plan is an organisation without a plan.
The problem with plans is when we become bound to them, following them slavishly, failing to review them and update them based on new knowledge.
That’s when tickets are awful. You’re doing a ticket because somebody you don’t know raised it for reasons you don’t know at some point in the past. Having “delivered” the ticket, you’ve no idea whether you’ve made any impact on anybody’s life, so everything feels like a waste of time.
When tickets are done well, they are related closely to the impact they’re supposed to deliver, and represent a conversation about everything we’ve learned about that expected impact.
A good ticketing system feeds into and is used by bug trackers and work planner/trackers. It instantaneously opens tickets from a variety of sources. Every ticket has a state, which starts out as New, and eventually winds up as Resolved, Requestor Did Not Reply, or Could Not Replicate. In between, there are various states of work that translate into Ready for Work or Waiting for Response, different queues for different groups in the company (and the ability to move a ticket between queues), automatic resetting of tickets to Ready for Work whenever a response comes in from the requestor...
Then there are the necessary features: merge duplicates (and from then on, both ticket numbers are valid but indicate the same data); declare a parent (when the parent ticket reaches a final state, all children get the same final disposition); correct and document mistakes...
You'll notice that all of these things reinforce how the business thinks the requestors should be treated: as customers, as teammates, as people who would like to report a problem, ask a question, place an order, document some work... but above all else, be able to ask what is going on with their area of concern and be able to get a reasonable reply as soon as one is available.
If your ticketing system is not oriented to perform that basic task as a primary activity, it's terrible and I hope you can replace it with one that does without too much pain.