Not sure if the tickets are really the problem. I've used them both in places that are soulless and places I've loved, because they're an effective tool for tracking a lot of things happening.
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.
> But that combines with the idea that your work = your worth, which is completely untrue
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
I often commit small org-mode style Todo files right in the repo (for personal projects), and it actually helps to see how the Todo list evolved with the project. It ends up not being a transient list of random stuff to do, but an evolving vision for the future. Maybe there's something to it...
The strategy that has made me most happy is to divide my work time almost in half. Half is regulated, doing tickets, choosing the high priority long term work, documenting, and moving milestones. The other half, I always work on the most recently requested thing of me, or really whatever sounds fun, no matter how small or stupid it is, and I don't guilt myself over it. It has worked really well!
My issue with ticketing systems is similar to most issues I have with this industry: cognitive dissonance.
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.
That’s not cognitive dissonance. It’s just the tendency of human ambition to outstrip action because of myriad reasons - lack of expertise normally being the root cause. It’s the same reason my shed is filled with expensive tools I’ve used once.
Don't make me context switch between being an engineer/designer and being a bureaucrat. That's all I ask. (Okay, not all. It'd also be nice to have ticketing/project management software that isn't super ugly, clunky, and slow.)
It really does feel like reading comprehension limitations are a major barrier to people helping themselves.
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 worked under a director whose resume padding for the job was going to be switching from JIRA to Salesforce for tickets. JIRA worked well for engineers and QA, but management wasn’t getting the types of reports they wanted. Reportedly. Our JIRA implementation had evolved over several years and we had 50-100 people familiar with it and happy with it.
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.
There's definitely something to having face-to-face interactions. When I worked IT, I loved coming upon someone's problem, diagnosing and fixing it there, and making their day. I just am not able to do that behind a ticket system. Though sometimes I _like_ the predictability and transactionality of fixing a ticket too...
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.
I feel like I was able to solve problems with less friction when I was working in IT. I found a lot of personal and organizational value working one-on-one with the reporter of some issue: directly reaching out to them for more information, assuring them the issue is being investigated, serving as a liaison and sometimes hand-holder in its resolution, and leaving succinct notes and documentation for the next person who might come across whatever the problem was. Today, I don't get this same sense of 'ownership' over fixing a bug, or implementing some incremental sub-sub-feature in software engineering; at times I feel that I am not being trusted to interact with the reporter at all.
There is a tendency for humans to want to systematise everything. We organise our bookshelves, write precise cooking recipes, track exercise routines. It brings comfort in chaos because it feels like there’s a plan.
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.
Tickets by themselves are a symptom of a good process and not the end goal. If you don't know where tickets come from, why they exist, or when to do them, then the whole process is nonsense.
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.
Ticketing (really, work tracking) needs to be adapted to each organisation. This is of course not a complete list, but some patterns I've seen:
- 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.
A bug tracker is not the same as a work planner/tracker which is not the same as a ticketing system.
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.
20 comments
[ 2.7 ms ] story [ 55.0 ms ] threadMaybe 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
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.
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!
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.
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.
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.
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.
- 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.
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.