People are super-creative when it comes to using tools - in a good and ... not-so-good sense. Sometimes they dig out incredible new scenarios the tool's creators never thought about, but sometimes they twist, exploit and spoil good intentions for the sake of their personal convenience, comfort or the sense of security.

One of the most irritating (& common) cases of such kind is typically linked with a widespread issue tracker turned project/product management tool - Jira. Which case do I mean?

1. A member of Team X identifies some sort of dependency on team Y's work/assets/knowledge
2. <sarcasm mode=on> To avoid the worst nightmare every developer fears to face - direct communication - team X issues a ticket (in Jira) to team Y </sarcasm>
3. The ticket includes a development demand/expectation, question, a request for confirmation/acknowledgment, etc. - something team X expects of team Y, but is reluctant to ask about it face-to-face
4. All the "collaboration" happens via task-related comments and re-assigning the task back to the previous team

But, but ... it's async!

So what's wrong about it? At first glance, everything seems about right:

• The ticket is asynchronous, so there's no interruption - productivity appears unharmed ("no bloody meetings! hooray!")
• The request is registered and persistent - everyone can see it (transparency), track it, watch it, prioritize it, etc.
• All the communication that happens in the context of this particular task is associated to the ticket - the full record is available for tracking/audit purpose
• Such a mode of work seems very remote-friendly

So why not follow that idea even further? Make every interaction a ticket. Turn all the processes into Jira projects. Let the fieldsets and status lists mimic 1:1 the reality and its laws/constraints.

In other words: Jira all the things! (yes, some companies really do scale that way!)

Fast, yet slower

No. Seriously. That is so very wrong.

I don't mind the (theoretical) order introduced here, but the drawbacks are overwhelming:

• first of all, the cost of eliminating interruptions is the increased cycle time - because the actual amount of time spent actively on the task is just a fraction of time that task spends in the queues; in the end: everyone is fully utilized (efficient), but the overall flow of work is very slow (not effective)
• Jira's mental model forces the particular idea of ownership (aka "hot potato") - a person responsible for the task is the one who's currently assigned to it; it pretty much means that the problem is off (you) once you re-assign the issue to someone else - that kills the idea of true accountability (or at least doesn't help it)
• it doesn't punish (or even discourage) the "ping-pong" - highly inefficient scenario when several parties keep bumping the task over the "fence" between themselves many, many times (e.g. single "yes/no" question = at least 2 bumps)
• every "actor" sees only her/his perspective, so this is more choreography than orchestration scenario: that's why systemic problems are not that easily visible and it's hard to get the big picture; in general, it's hard to get rid of the feeling that it's the system that rules the people, not the other way around

Obviously, it's not Jira (the tool) to be blamed. Such patterns of usage just do reflect the issues in the organization's culture. The tool only amplifies the detrimental tendencies.

Sum it up

I guess it's time for some conclusions:

1. looking at your work only from the perspective of individual efficiency is a grave mistake; what matters much more is team/group/unit effectiveness - do you track the cycle time for the work performed in your organization?
2. don't fool yourself - it's NOT advisable (for the wanna-be-effective organization) to do everything asynchronously; accept the fact that there's a need to handle urgent and critical (the most important) work differently
3. for every "item" of important work there has to be someone (at least one person) pushing it further continuously (even when it's someone else's time to work actively on that) - that's why the tooling needs to embrace, support and reinforce the idea of explicit accountability
4. each time people are having a discussion (ask questions, debate, comment, etc.) in Jira task's comments, a fairy dies in Neverland (and I have an urge to fire someone ...) - it's one of the WORST ways to have a fruitful discussion I've EVER encountered, a literal money-sink; instead, you should have an efficient, condensed conversation out of the tool and attach the summarized outcome for the future reference
5. there's an old saying in software engineering: "if it hurts, do it more often" - handling dependencies by raising tickets to other teams doesn't solve any issue, just transfers the responsibility for the issue (and makes it more obscure); the healthy reaction is to reduce the dependencies or to loosen them in a way that makes them less constraining (e.g. by clumping up the work, taking over some scattered responsibilities, avoiding breaking changes or introducing automation)
6. excessive asynchrony + high level of dependency = switching you permanently into the re-active behavioral mode, which is extremely detrimental when it comes to creativity

You probably won't truly understand the importance of this issue (and how severe it is) until you face it yourself. For me, it was a huge blow when I was asked (as an Executive (!)) whether I prefer to have the requests to myself raised as Jira tickets assigned to me or is the mail "just enough." I'm not bullshitting you here - it has REALLY happened - more than once (but all the cases within one organization).