The ticketing system user interface is an antipattern for cross-team collaboration#

If your team spends most of its time managing a ticketing system — filing requests, triaging queues, waiting for answers — you have already made your collaboration legible to a machine.

That is not a metaphor. Ticketing systems only work for the kind of work AI handles well: routine, well-defined, known destination, repeatable process. If your collaboration looks like a queue, it can be automated. And it will be.

What AI cannot do — not yet, maybe not ever — is the work that starts with I don’t know. The ambiguous, creative, cross-functional discovery that produces genuinely new things. The conversation between a designer and a data scientist that leads somewhere neither of them expected. The relationship that makes the next hard question feel safe to ask out loud.

That work requires human beings. And it requires something ticketing systems are architecturally incapable of providing: relationship before transaction.

This is the problem. We are automating the easy stuff and bureaucratizing the hard stuff. And most organizations have no idea they’re doing it.

You already know what a ticketing system feels like from the outside. Think of the last time you contacted customer support — not a great product that solved your problem before you even asked, but a real support ticket. You described your issue as best you could, hit submit, and waited. The reply came back with a case number and a question that made you wonder if anyone had actually read what you wrote. You answered. You waited again. Eventually, maybe, your problem was solved — or it wasn’t, and you gave up.

Now imagine that’s how your colleagues experience asking for help from your data, design, security, or platform team. Every day.

Ticketing systems make perfect sense for the team that owns them. They bring structure to an otherwise chaotic stream of requests, create accountability, and give the specialized team control over their own prioritization. From the inside, it looks like a well-oiled machine. None of this is malicious.

But nobody designed it for the other side.

This is a real experience. I have lived it from both sides — as a member of a cross-functional product team blocked by ticketing systems, and as part of specialized teams that used them to manage demand. This post is for product, UX, and engineering leaders who suspect something is broken in how their teams collaborate, but can’t quite put their finger on what.

Relationship before transaction#

There is a principle so deeply human it predates civilization: relationship before transaction. You don’t ask a stranger for a favor. You meet them. You share something. You build trust. Only then does asking feel natural — for both sides.

Every culture in the world operates this way. It’s how villages traded, how guilds were built, how business has always actually worked beneath the formal processes. The Agile Manifesto captured it simply: people and their relationships over processes and tools.

Ticketing systems invert this completely. They demand the transaction first. The relationship, if it ever comes, comes later — if at all. And when the transaction inevitably goes badly — because the context collapsed, because the request was ambiguous, because the answer took three weeks — there is no relationship to fall back on. Just a case number.

Actors and scope#

• Cross-functional team: a team of professionals from diverse horizons (engineers, product managers, designers, etc.) working to achieve a positive outcome for the organization.
• Specialized team: a team that has no representation in the cross-functional team.
• Requester: an individual from the cross-functional team submitting a ticket on behalf of the team.

What this article does not cover#

Support ticketing systems are out of scope. Support is about homeostasis — the system broke, we know what “working” looks like, we follow a process to restore it. That work is well-defined, repeatable, and increasingly AI-automatable. It is not cross-team discovery.

Internal team ticketing systems — where a team voluntarily adopts a ticketing system for its own use and retains full control over how it evolves — are also out of scope. If the team owns the tool and can reshape it, the dynamic is different.

This article is about ticketing systems imposed on cross-functional teams as the primary interface for collaboration with specialized teams — with no shared ownership and no feedback loop.

Three reasons it is an antipattern for cross-team collaboration#

1 - It causes a contextual information collapse#

In a cross-team effort, context is king. Concepts and ideas about the future are notoriously hard to share. Even if you have created artifacts to share your context — product brief, design doc, prototype, user interviews — and even if you manage to attach all of them to your request, you have no idea what will be done with that content. Will someone even open it?

Every ticketing system forces a collapse of context. It coerces the requester to comply with the worldview of the ticketing system owner: short description, priority, is it blocking, which team. As a requester, you can add context — but will it be used? How? Will it still be accurate in a week? A month?

Some specialized teams go further: they prevent any conversation from happening before a ticket is created.

2 - Ticketing systems require clarity you don’t yet have#

Ticketing systems are well-suited to one type of work: well-defined problems with a known solution path. That is exactly what support is — something broke, we know what “working” looks like, we follow a process to restore it. Standard Operating Procedure.

Discovery work is structurally different. You start from a place of vulnerability and curiosity — and that is not a weakness. It is the beginning of the work.

Tickets kill both.

Vulnerability dies first. Not only does the form demand clarity you don’t have yet — it puts you on record for not having it. Your “I don’t know what to ask” is now a permanent entry in a system, visible to the team, waiting to be triaged and judged. So you self-censor. You write something that sounds more confident than you feel. You shrink the question to fit the box. The real need never makes it in.

Curiosity dies next. A ticket implies a destination. You’re not exploring — you’re filing. The open-ended I wonder if these two things are connected becomes “request type: question, priority: medium.” The conversation that might have led somewhere unexpected never happens.

I lived this directly. We had qualitative evidence — user interviews — pointing to a friction point in one of our product flows. But I couldn’t tell if it was a copywriting issue, an information architecture problem, a performance issue, a branding mismatch, or something else entirely. The right next step wasn’t a ticket. It was a conversation with two or three people who together might triangulate the problem.

A ticket form is architecturally incapable of handling this. It demands a clear description, a priority, a team. It asks you to have already done the discovery before you’ve started it.

3 - Bad transactions erode relationships — and eventually, people stop asking#

Relationships and transactions are not opposites — they depend on each other. A strong relationship makes transactions feel natural, even easy. A weak or nonexistent relationship makes every transaction a small ordeal. And every ordeal leaves a residue.

The problem with ticketing systems is that they are purely transactional by design. No relationship precedes the transaction. No relationship is built by it. And when the transaction goes badly — the context was lost, the answer took three weeks, the reply missed the point — there is nothing to absorb the frustration.

Over time, something predictable happens: people stop asking.

Not because the problems go away. Because the cost of asking — the vulnerability of filing a ticket you’re not sure how to write, into a system you don’t control, with no visibility into what happens next — becomes higher than the cost of working around the problem. This is learned helplessness. People stop expecting the system to work for them, so they stop using it. They find workarounds. They stay in their lane. Silos deepen — not by policy, but by accumulated discouragement.

And when learned helplessness sets in, some people don’t give up — they go around. They find a colleague who owes them a favor. They get direct database access. They reverse-engineer the tool themselves. They pull in someone from their own team to approximate what the specialized team would have done.

This looks like resourcefulness. It is actually a quiet organizational failure. The workaround works — once. But the knowledge stays siloed, the specialized team loses visibility into how their systems are being used, risks accumulate invisibly, and the real problem is never surfaced or solved properly.

The most dangerous outcome isn’t frustration. It’s that the ticketing system reports green while the organization is quietly bleeding.

There is another victim in this story: the specialized team itself. When workarounds become the norm, the specialized team loses visibility into how their systems are actually being used — sometimes in ways that matter at the highest levels. I witnessed a report built by a product team that made it all the way to the board. The data team, who had been bypassed, had no idea where the numbers came from. They couldn’t vouch for the methodology. They couldn’t answer questions. The workaround that “solved” a collaboration problem created a much bigger one — invisibly, until it wasn’t invisible anymore.

The silence looks like alignment. It isn’t.

4 - What can you do about it?#

There are no silver bullets. This is fundamentally a leadership and organizational design problem. But here are three solutions in order of impact.

The ideal solution: change the team composition. Add the specialty you’re missing directly to the cross-functional team. Can you add a full-time data scientist? A full-time product marketing manager? This eliminates the need for any ticketing interface entirely — the expertise is in the room.

If not full-time: negotiate at least half-time commitment. A data scientist or designer working across two product areas can still attend rituals, maintain alignment, and move at the team’s pace. In my experience, the ability to maintain alignment drops rapidly below half-time — very fast for junior members, more slowly for seniors who can sometimes manage three or four team memberships simultaneously. Below half-time, don’t expect real collaboration.

If neither is possible: you have an organizational design problem. One or more specialized teams are being silently overcommitted across too many fronts. Cross-team collaboration will suffer, velocity will drop, and employee morale will follow. This is a negative feedback loop. Work with your leadership to surface it — the experiment below is a fast path to making it visible.

5 - If you are stuck with a ticketing system: three softeners#

If none of the above is actionable yet, there are things you can do to reduce the damage without overhauling the system.

5.1 - Enable conversation before the ticket#

Run office hours. The specialized team holds a few weekly open sessions — across timezones if you’re distributed — where potential requesters can come with exploratory questions, no ticket required. The goal is relationship first, then context sharing. It meets the needs of both sides: the specialized team gets connection, clarity, and better-scoped work; the cross-functional team gets to be heard and understood before committing anything to a form.

5.2 - Have the specialized team member write the ticket#

The requester has context the specialized team doesn’t have. The specialized team has domain knowledge and process expertise the requester doesn’t have. The best outcome is when they meet first — ideally someone from the office hours — and the specialized team member writes the ticket after listening.

This is active listening in practice: I repeat back what I understood of your need. We align on feasibility and value together. The ticket captures the outcome of that conversation, not a substitute for it. It is also a win for the specialized team: they control the format, can provide an estimate, and sometimes even offer a tacit timeline commitment.

5.3 - Create a feedback loop#

Systems without feedback loops diverge. What is the feedback loop of your specialized team’s ticketing system?

Most companies measure customer NPS, employee NPS, run retrospectives on product teams. But who is surveying the users of the internal ticketing system? Are they satisfied? Do they feel heard? Do they have ideas to improve it?

Without this retroaction, the ticketing system is a one-sided black box that will silently accumulate dysfunction. There is no perfect system — but a system with no feedback loop cannot improve.

Is leadership aware? A practical experiment#

Most leaders have never used the internal ticketing systems their organizations depend on. When a senior leader needs cross-team collaboration, a dedicated task force is assembled. Their request is prioritized immediately, scoped flexibly to handle ambiguity, and staffed with experts.

Leaders systematically bypass every internal ticketing system.

They have no idea what it feels like to use one.

In product and design, we call this dogfooding — using the product you’re responsible for. In this case, the product is your organization’s collaboration infrastructure.

The experiment: for one week, use exclusively the interfaces available to everyone else. Every time you need something from another team, file a ticket. When someone needs something from your team, refer them to your ticketing system. Take notes.

Do this every quarter and bring the findings to your QBR.

If you don’t have the time for direct experience, use discovery methods instead. Talk to individual contributors — people with no managerial role — and ask them to show you how they collaborate across teams. Ask new hires after their first three months: what would you change to make cross-team collaboration easier? Open questions, active listening.

Leaders are the designers of the organization. Like any design, the tradeoffs have to be measured — because the right tradeoffs today may be the wrong ones in six months.

Conclusion#

We are automating the easy stuff and bureaucratizing the hard stuff.

The work that remains irreducibly human — ambiguous, creative, cross-functional discovery — requires vulnerability, curiosity, and trust between people. It requires relationship before transaction. Ticketing systems are architecturally incompatible with that work.

The fix is an organizational design problem, not a tooling problem:

• For your highest-priority initiatives: embed the specialists. Eliminate the need for the interface entirely.
• Where that’s not possible: negotiate at least half-time commitment. Below that, real collaboration is unlikely.
• While you work toward that: run office hours, have specialists write the tickets, build a feedback loop.

And if you are a leader: try the system your teams use every day. One week. Then decide if the tradeoffs are still the right ones.

But beneath all of this is something simpler. Human beings have always built relationships before asking for favors. They have always shared a meal before signing a contract. They have always learned each other’s names before making a request. That instinct is not inefficiency — it is how trust is built, how context is shared, how the best work gets done.

A ticketing system skips all of that. And no amount of process optimization will replace what gets lost when you do.