The Underrated Skill of Writing Good Tickets

I have spent a fair amount of my career watching brilliant engineers ship the wrong thing. Not because they were careless, and not because they lacked the skill to build what was asked. They built the wrong thing because the thing they were asked to build was described badly. A vague ticket, a missing acceptance criterion, an assumption left unstated, and three days later we are in a retro trying to figure out how a perfectly competent team produced something nobody wanted.

Writing good tickets is one of the most undervalued skills in engineering, and in a regulated fintech environment it is closer to load-bearing than people admit. The ticket is the contract between intent and execution. When it is clear, the work flows. When it is muddy, the cost compounds quietly across every person who touches it. I want to make the case that ticket writing deserves the same craftsmanship we reserve for the code itself.

Why Tickets Are a Leadership Artifact

It is tempting to treat a ticket as administrative overhead, a box to fill before the real work begins. I think that framing is exactly backwards. A ticket is where a leader does their thinking out loud. It is the moment where intent is translated into something another person can act on without you in the room. If you cannot describe a piece of work clearly enough for someone else to execute it, you do not understand the work yet, and writing the ticket is how you find that out.

In my experience, the quality of an organisation's tickets is a remarkably honest signal about the quality of its thinking. Teams that write sharp, scoped tickets tend to have clear priorities and calm delivery. Teams that write one-line tickets full of pronouns and implied context tend to have a lot of meetings, a lot of rework, and a lot of frustrated senior people who have become the only humans capable of decoding what anything means. The ticket is not the bureaucracy. The ticket is the leadership.

The Anatomy of a Good Ticket

When I review a ticket, I am looking for a small number of things to be present and unambiguous. It does not need to be long. Some of the best tickets I have seen are four sentences. What matters is that the reader finishes it knowing what to do, why it matters, and how they will know they are done. The structure I keep coming back to is simple and durable.

• Context: why this work exists now, and what changes if we do nothing. A sentence of motivation prevents a hundred questions later.
• The problem or change: a precise statement of what is wrong or what should be different, written in the language of the user or the system, not the language of a half-formed solution.
• Acceptance criteria: observable conditions that, when true, mean the work is complete. These are the spine of the ticket.
• Constraints and out-of-scope notes: what we are explicitly not doing, which is often more valuable than what we are.
• Links: the relevant designs, prior tickets, logs, or compliance requirements, so the reader does not have to go hunting.

Notice what is missing from that list. There is no demand for a novel. A good ticket respects the reader's time as much as the writer's. The discipline is in including everything load-bearing and ruthlessly cutting everything decorative. The skill is knowing the difference, and that judgment is what separates a ticket someone can run with from one they have to interrogate you about.

Describe the Problem, Not the Solution

One of the most common failures I see is a ticket that leaps straight to an implementation. The title reads something like add a Redis cache to the balance endpoint, and the body describes the cache. The problem with this is that nobody wrote down the actual problem, which was that the balance endpoint takes eight hundred milliseconds at peak and is breaching our latency budget. Maybe a cache is the right answer. Maybe the right answer is a missing database index, or a chatty query, or a payload we are serialising three times. By specifying the solution in the ticket, you have quietly removed the engineer's ability to find a better one.

This matters more in fintech than almost anywhere, because the solution you reach for casually can carry consequences you did not intend. A cache on a balance figure is not a performance optimisation, it is a decision about staleness and correctness in a domain where customers and regulators care a great deal about both. When the ticket describes the problem, the person closest to the code can weigh those trade-offs. When the ticket prescribes the solution, those trade-offs get made silently and discovered in production.

The best tickets give the reader a problem to solve and the constraints to solve it within. The worst ones give them a solution to type out and call it done.

Acceptance Criteria as a Contract

If I could change one habit across an engineering organisation, it would be to make acceptance criteria non-negotiable. Acceptance criteria are the part of the ticket that answers a deceptively hard question: how do we know this is done? Not done in the sense of the code compiling, but done in the sense that the thing we wanted to be true is now true and we can demonstrate it.

Good acceptance criteria are observable and specific. A statement like the form should validate the user's input is not acceptance criteria, it is a hope. A statement like submitting the form with an invalid IBAN returns a 422 and the field-level error visible to the user is acceptance criteria, because it can be checked by a person who was not in the conversation. The act of writing them forces you to confront the edge cases up front, where they are cheap, rather than in QA or in a customer complaint, where they are expensive.

There is a second, quieter benefit. Acceptance criteria protect the engineer. When the work is done and the criteria are met, the ticket is closed, and nobody can move the goalposts after the fact by claiming they meant something else. In a healthy team this is rarely adversarial, but the clarity it provides removes a whole category of low-grade friction about whether something is finished. Done becomes a fact rather than an opinion.

The Hidden Cost of Vague Tickets

The damage from a bad ticket is rarely visible at the moment it is written. It surfaces later, distributed across many people, which is exactly why it goes unaccounted for. An engineer reads the vague ticket and has to interrupt their work to ask a clarifying question. They wait for an answer, which arrives in a meeting two days later. They make an assumption to keep moving, and the assumption is wrong. The reviewer cannot tell whether the implementation is correct because there is nothing to check it against, so they approve on trust. QA tests something subtly different from what was intended. The work ships, the bug appears, and now we are paying interest on a debt we took on the day the ticket was written in thirty seconds.

I have come to think of vague tickets as a tax that the writer avoids paying and the rest of the team pays at a much higher rate. The author saves five minutes. The team spends hours. This asymmetry is precisely why it persists, because the cost is invisible to the person creating it. Part of my job as a leader is to make that cost visible, and to make the small discipline of writing well the cheaper option for everyone, including the person tempted to skip it.

Tickets in a Regulated Environment

In a regulated fintech business, a ticket is occasionally more than a coordination tool. It can become part of the evidence trail. When an auditor or a regulator asks why a particular control exists, or when a change is made to how we handle customer funds or personal data, the ticket is often the first artifact someone reaches for. It records what was changed, why, who approved it, and what we believed the impact would be. A thin ticket is not just an inconvenience to your colleagues, it is a gap in the record of how the business actually operates.

This does not mean every ticket needs to read like a legal document. It means that for work touching sensitive areas, payments, reconciliation, access control, data retention, the ticket should make the reasoning explicit and link to the requirement it satisfies. I would much rather an engineer write one extra sentence connecting a change to the regulation that motivated it than have us reconstruct that reasoning from memory eighteen months later under audit pressure. The discipline of the ticket and the discipline of compliance turn out to be the same discipline wearing different clothes.

Splitting Work Into Honest Units

A surprising amount of ticket quality comes from sizing rather than wording. A ticket that tries to capture a whole epic will inevitably be vague, because no four-sentence description can faithfully represent two weeks of work with a dozen decision points inside it. The skill of breaking work into units that are each independently understandable and verifiable is, to me, inseparable from the skill of writing the tickets themselves.

The test I apply is whether a ticket represents an honest unit of progress. Can it be picked up, completed, reviewed, and merged without dragging three unrelated concerns along with it? When I see a ticket that touches the database schema, the API contract, the frontend, and the deployment pipeline all at once, I do not see a big task, I see four tasks that have been stapled together and will now be reviewed badly because the reviewer cannot hold all of it in their head. Splitting that into honest units is not bureaucratic ceremony. It is how you make the work reviewable, and reviewability is how you make it safe.

Building a Culture of Good Tickets

You cannot mandate good ticket writing into existence with a template alone, though a lightweight template helps. Culture is built by what leaders reward and what they tolerate. If I want my teams to write good tickets, the most effective thing I can do is write good ones myself, and then treat poorly specified work as something to fix before it enters the backlog rather than something to grumble about after.

I have found a few practices that move the needle without turning into process for its own sake. Refinement sessions should spend their time sharpening tickets, not narrating them. A senior engineer who rewrites a junior's ticket should do it alongside them, explaining the why, so the skill transfers. And when a ticket turns out to have been ambiguous, the fix belongs in the next retro as a learning, not as a blame. The goal is to make clarity the path of least resistance, so that writing a good ticket feels normal rather than heroic.

Conclusion

Writing good tickets will never feel as glamorous as designing a system or shipping a feature, and that is exactly why it stays underrated. But the ticket is where intent becomes action, where a leader's thinking is tested against the cold reality of someone else having to execute it, and where a regulated business quietly records the reasoning behind its changes. Treat it as the craft it is, and you buy yourself clarity, speed, and a team that spends its energy building rather than decoding. I would take a team of mediocre coders who write excellent tickets over a team of brilliant ones who write terrible ones, almost every time, because the first team knows what it is doing and the second only thinks it does.