The team I’m on is in IT but we’re just one small team. Our responsibilities are narrowly defined; we’re responsible for just one small piece of the action. This is a consequence of a combination of a large organization, public sector service, and union contracts.
The goal of the larger organization, IT, is to solve problems, so, in total, we solve problems. However, problems don’t always come nice and neat and narrowly defined. Often they’re messy and complex and they take more than one team to fix… or at least resolve.
Luckily the many separate teams of IT have a tool that was sold to us as a “communications tool”. It’s a database that is supposed to be used to collect customer problems in one virtual place, generates trouble tickets for those problems, and that all of the teams of IT refer to and update and check off as we all complete our parts of the problems that customers have.
But because of the vagaries of customer problems, and the minutia of communication in general, and the fact that no database can be designed to cover every possible interaction of fallible imperfect human beings… sometimes things get lost in the process.
Know what the difference is between a “system” and a “process”? A process takes an input, and generates an output. A system then adds feedback; was that output the right output? How can we make it better? Systems are circular.
IT does really well with processes. Systems, not so much. Or maybe that’s just the IT department I work for.
My team got an email the other day from someone on another IT team, asking about a customer problem that we had shared responsibility for. In the email, the tech asked a simple question: “Can this ticket be closed?”
Simple questions often aren’t. I don’t know; can this ticket be closed? I mean, it’s possible to close the ticket. It’s a simple matter of choosing “closed” and clicking “save”. But I’m sure that’s not what she meant.
The ticket in question is weeks old, and there were no notes in the appropriate fields showing that the customer, or the customer’s boss, had called in to complain that the work in question (it was a request for work to be done, not a crash or problem that needed resolving) had not yet been done. Since the work wasn’t a high priority, and my team is strapped for time and resources, if I had noticed this ticket still in our bucket, I would have been sorely tempted to simply log that the customer seemed happy enough not to complain (covering my ass in case of review) and closing it. But that’s not our process.
In the strictest terms, we could only close a ticket if the work had, in fact, been done. That was the most correct interpretation of the tech’s emailed question.
Our boss copied everyone involved on his reply, but directed his response at my team. “Is this done?”
Ah, now my boss is asking a different question. “Is this done?” Standing by itself, what does that sentence mean? It hinges on what “this” is referring to, doesn’t it? Is “this” pointing at the previous email from the tech and referring to the action of “closing the ticket” that she specifically asked? Or does my boss’s “this” refer to the strict interpretation of her question and the process of “work done; close ticket to document”?
Since my boss supervises our work and therefore holds the responsibility to discipline in case work is not done, the best interpretation of his question would include the assumption of the process we have in place for actually getting work done. I mean, if one was going to overthink things, that’s the assumption that would result in the most happiness; for us, the customer, and the other IT teams.
One could interpret my boss’s question as just being about the actual process of closing the ticket. But that path, while strictly logical and defensible in a linguistic sense, isn’t politically viable.
So my teammate makes a couple phone calls for information from the customer, and then replies to our boss and the other tech (and copies my team) with, “I checked with the customer and it’s done.”
His response seems to cover all bases. He mentions calling the customer, which implies that they are satisfied with whatever happened, and he uses the phrase “it’s done”.
But again, the language barrier of ambiguity strikes. What is “it” that is now “done”? Is “it” the ticket being closed, or the work that was requested by the customer?
Because our boss responds with “But is the ticket closed?” Frustrating, in that it circles back to the original choices presented by the other team’s tech and her question. Can the ticket be closed? Isn’t closing the ticket just the last step in the process of resolving customer problems? Or is it a separate act in itself?
Didn’t my teammate address this with his reply? Or should he have gone into more detail about everything he’d done – called the customer, asked if the work was done, documented and closed the ticket, then replied to our boss?
Is it any wonder there are so many barriers to getting work done at my job? We spent at least a half-hour, maybe more, parsing all the ambiguities of this exchange to try to figure out what, exactly, our boss wants from us and how best to communicate back and forth with him and other teams.
What is “it”? It’s it.