Training Data

Datadog Ticket: Lessons in Problem-First Ticket Writing 

Đăng vào bởi Gong Elijah

A ticket is not a to-do item. It is a problem-solving process written down and made visible to other people. If the problem is not clear in your own mind, the ticket will betray that — and so will the work that follows from it.

I want to trace this through a single personal example: a Datadog monitoring ticket I worked on. At first glance it seemed simple — set up Datadog. But the process of getting that ticket right taught me more about problem-solving than any abstract framework could. Every section below picks up where the last left off, following the same ticket from vague instinct to something genuinely executable.

The Foundation: Problem = Reality vs Expectation

Everything begins with a deceptively simple equation, introduced in Vatico’s problem-solving training:1

Problem what we are solving
=
Reality what is currently true
–
Expectation what should be true

Applied to the Datadog ticket, this forced two distinct sentences before anything else was written:

Reality

Reconciliation failures are currently silent. There is no alert or log surfaced to the team, so errors only come to light when an analyst reads a downstream report and notices the numbers don’t make sense.

vs
Expectation

When a COD reconciliation failure occurs, the team should know about it immediately — with enough context to investigate and resolve it.

Gap identified. Now there is something concrete to solve.

Without writing both of these down, the ticket stays permanently vague. “Set up Datadog” is a solution, not a problem. The equation forces you to name the gap before you reach for the tool.

Before the Ticket: The Three Questions You Must Answer

Between naming the gap and writing the ticket, there is a thinking stage that should not be skipped. This is where interns — myself included — tend to reach for the keyboard too early. The Datadog ticket is a direct example of all three questions needing answers before a single field could be filled in honestly.

Understand why we need to fix it in the first place

Think of COD reconciliation like comparing cash collected to items shipped.3 For this Datadog ticket, understanding the business flow meant knowing why we need to fix this: if payment checks break silently, finance numbers stop matching without anyone noticing. Knowing where this piece fits prevents us from building a fix in the wrong place.

What is the intended outcome — and what does “done” look like concretely?

Before building anything, you need a clear picture of the final result — just like drawing a plan before building a Lego model.2 For this ticket, “done” meant creating an alarm bell in Datadog that rings immediately when a job fails, telling us exactly which job broke and when. Having this clear target upfront ensures we know when the work is truly finished.

Do we need to break this task smaller?

The problem-solving framework is about divide and conquer.4 When a task feels too big, you break it down into smaller, realistic sub-tasks and solve them step by step. Applying this tree-like breakdown is a good reminder for us to break down tasks first, especially if we notice the scope of a ticket getting too large.

Anatomy of a Good Ticket at Vatico

With the problem understood, the ticket becomes the container for communicating that understanding to everyone else who will touch the work.5 Here is what the Datadog ticket looked like before the thinking was done — and after.

First Draft ✗
Objective

Set up Datadog for the team.

No background. No deliverable. No action items. Nothing here tells anyone why this exists or what done looks like.
→
After Reflection ✓
Background

COD reconciliation failures occur silently without any alerting mechanism, so errors only surface when an analyst reads a downstream report and notices the numbers don’t make sense.

Objective

Implement Datadog monitors on COD reconciliation jobs to surface failed reconciliation mappings in real time.

Problem anchors the objective. Each field that follows has something to refer back to.

The remaining fields of the revised ticket each do a specific job:

Datadog Ticket — Completed Structure
Background
COD reconciliation failures occur silently without any alerting mechanism, so errors only surface when an analyst reads a downstream report and notices the numbers don’t make sense. This is the problem statement — reality and expectation made explicit.
Objective
Implement Datadog monitors on COD reconciliation jobs to surface failed reconciliation mappings in real time. Maps directly back to the gap in the background — no divergence.
Deliverable
A Datadog monitor per reconciliation job, each configured to alert with job name, timestamp, and error type on failure. Concrete enough that “done” is unambiguous.
Action Items
1. Confirm with supervisor which reconciliation jobs produce structured error states (dependency — flagged first). 2. Define alert triggers and notification channels with supervisor. 3. Configure monitors. 4. Test with a simulated failure. Dependencies surfaced upfront, not mid-sprint.
Definitions
“Failure” = any job that does not complete with a success status within the expected window. “Silent failure” = a job that completes but produces incorrect output — out of scope for this ticket, flagged as a follow-up. Removes ambiguity before it causes rework.

The flow is strictly top-down. The background defines the objective. The objective defines the deliverable. The deliverable defines the action items. Each field earns its place by referring back to the one above it.

Where Tickets Go Wrong

First drafts often fail because of predictable shortcuts. Naming these 5 common anti-patterns makes them easier to avoid at a single glance:

1. Solution Written Before Problem Is Clear

Tickets should not be focused purely on solution writing. We write tickets to communicate the problem and desired outcome so clearly that the problem itself makes complete sense.

2. Stopping at Symptoms Without Naming the Core Problem

Listing downstream symptoms (like regulatory violations) is good practice and provides helpful context. The issue is stopping at symptoms alone without defining the root problem (e.g. reconciliation finance numbers don’t make sense).

3. Vague or Missing Deliverables

Be detailed about the concrete outcome (e.g. sample output tables, exhaustive column specs) so the planned solution is fully clear before implementation begins.

4. Unflagged Upfront Dependencies

Use action items as a checklist to flag required dependencies before execution such as data sources, file formats (JSON/CSV), datetime elements, and typecasting rules.

5. Objective Doesn’t Map Back to the Problem

Always map the objective directly to the background gap. Without a clear problem anchor, reviewers cannot judge whether the proposed approach is justified.

None of these were failures of technical skill. They were all failures of thinking that happened before a single tool was opened. The ticket preserved the confusion rather than resolving it.

The Self-Check Before Submitting Any Ticket

Can a new team member read this ticket and understand why it exists, what done looks like, and how the solution connects to the problem — without asking anyone?

The first draft failed this test immediately. The revised version passed — a new intern could read the background, understand the gap, follow the objective back to it, picture the deliverable, and know exactly which action item to start with and which dependency to raise first.

What This Changes About How I Work

The Datadog ticket did not feel hard when I first wrote it. That was the problem. “Set up Datadog” felt complete because it was actionable — I could have started immediately. What it lacked was any proof that the right thing was being built, or that the scope had been considered, or that the people who needed to be involved had been identified.

Working through the revised version took longer upfront. Even though the ticket was ultimately backlogged and we did not work on it in the end, properly structuring it ensured that the problem, dependencies, and deliverables were completely clear. If it is ever picked back up, anyone can execute it without clarifying questions or mid-sprint redirects. The time spent thinking was not overhead — it was the cheapest possible moment to catch a mistake before any execution began.6

A ticket is a written-down problem-solving process. If you cannot write a good ticket, you have not yet fully understood the problem. The Datadog example made that concrete for me — not as a principle, but as something I had to work through myself, in the gap between a first draft that felt done and a revised version that actually was.

References

Gong Elijah