Why Tickets Exist

Team knowledge stored only in heads is team knowledge with a single point of failure. An engineer who "just knows" how the deploy pipeline works, which environment variables are required, or why the auth service has that weird retry logic is carrying institutional memory that the rest of the team can't access, search, or verify.

Tickets externalize that knowledge into a shared, searchable system. When an engineer creates a ticket for a piece of work, they're not just tracking a task — they're recording that the work exists, what it requires, and why it matters. Six months later, when someone asks "did we ever fix the race condition in the payment flow?", the answer is a search query, not a Slack message to someone who may have left the company.

The alternative — keeping work in heads, Slack threads, and sticky notes — works for a 3-person team in one room with perfect memory. It breaks the moment someone goes on vacation, switches projects, or quits. Every piece of knowledge stored exclusively in one person's head is a bus-factor risk the team is choosing to carry. Tickets don't eliminate the need for conversation, but they give those conversations a durable artifact that outlasts the people who had them.

Every non-trivial decision in a codebase eventually gets questioned. "Why did we add this endpoint?" "Who decided to drop support for IE?" "When did the pricing logic change?" Without tickets, answering these questions requires archaeology — digging through Slack, pinging former teammates, reading commit diffs and guessing at intent.

Tickets create a decision trail. Each ticket records who requested the work, when it was prioritized, what the acceptance criteria were, and — through linked PRs and commits — exactly what code changed to fulfill it. This isn't busywork; it's the difference between "I think we changed that in March" and "here's the ticket, the PR, and the review discussion."

Traceability also matters for compliance and incident response. When a production bug surfaces, the question "what changed recently?" should take seconds, not hours. A team with good ticket hygiene can trace from a deploy to a merge, from a merge to a PR, from a PR to a ticket, and from a ticket to the original request. A team without it is reading git log and guessing.

Tickets are the coordination layer for teams that can't be in the same room at the same time. In a co-located team of three, you can coordinate by turning your chair around. In a distributed team of eight across three time zones, "just talk to each other" isn't a coordination strategy — it's a wish.

A ticket system gives every piece of work a stable URL, a status, and an owner. An engineer in London can pick up a ticket, see what's expected, check the acceptance criteria, and start working — without waiting for the engineer in San Francisco who created it to wake up. The ticket is the async handoff point.

This scales down as well as up. Even a co-located team benefits from async coordination when people are in meetings, out sick, or deep in focus work. The ticket is always available. The person who wrote it isn't.