Context Infrastructure vs. Project Management: Why They're Not the Same Thing

Teams that already use Jira, Linear, or Asana often resist the idea that they need anything else. "We have our tickets. We have our sprints. We have our velocity charts." This is a reasonable objection, and addressing it requires being clear about what project management tools actually track versus what context infrastructure tracks.

Project management tracks outputs: tasks, completion states, assignments, timelines. Context infrastructure tracks state: what's actually happening, what was decided, what's at risk, what the next person needs to know. These are related but genuinely different things.

What project management tools do well

Task management tools are excellent at the objective layer of work: this feature needs building, these subtasks exist, this PR is in review, this item is blocked by that dependency. They create a shared model of what work exists and what its current status is. For managing backlogs, planning sprints, and reporting on progress to stakeholders, they're the right tool.

Where they fall short is in capturing the interpretive layer. A ticket can be "In Progress" for three days while the engineer has quietly discovered that the original spec is wrong, tried two approaches that didn't work, and decided to use a third approach that has implications for a different part of the system. None of that is in the ticket. The ticket says "In Progress" and the assignee is still the same engineer. The status is technically accurate and practically useless.

The gap between ticket status and actual state

Ticket status is designed for accountability and reporting. It answers: who is responsible for this, and is it done? Context is designed for coordination. It answers: what does the next person need to know to continue this work, and what decisions need to be understood to avoid stepping on them?

These are different questions with different answers, and conflating them is a source of persistent friction in distributed teams. When the engineering manager asks "where are we on the auth refactor?" and the answer is "in progress," that's a project management answer. The coordination answer is: "The core token logic is done, but we hit an issue with the refresh flow that required rethinking the session state model. That decision was made on Tuesday and has implications for the mobile client. Sarah knows the details; she's off today."

Why adding more fields to Jira doesn't solve it

The intuitive fix is to add more fields to the ticket: a "notes" field, a "decisions" field, a "blockers" field. Some teams do this and find moderate improvement. The problem is that filling in these fields requires a behavioral change — engineers have to remember to update them, in real time, with the right level of detail. In practice, this habit doesn't stick. The fields stay empty or get filled with stale information.

Context infrastructure works better when it's decoupled from the task management system. A separate, structured record written at the end of each shift captures state more reliably because it happens at a defined moment (shift end) and has a defined structure that prompts for the right information. It doesn't require remembering to update a field mid-task; it's a single deliberate act at the end of the day.

The right relationship between the two

Project management and context infrastructure are complementary, not competing. The project management tool manages the work queue. The context infrastructure captures the state of the work in progress. Engineers reference ticket numbers in their context records; context records explain the reasoning behind ticket updates. Both become more useful when used together than when either is used alone.

Frequently asked questions

Can we build context infrastructure inside our existing project management tool?

You can approximate it, but it tends to be awkward. The structure of most task management tools optimizes for tracking individual tasks, not for capturing the cross-cutting state of a person's work across multiple tasks in a single record. A standalone context record — one document per engineer per shift, covering all their active work — is often cleaner and more useful than ticket-level notes scattered across multiple cards.

Should engineers link their context records to tickets?

Yes, when relevant. Referencing ticket numbers in shift-end records makes it easy to find the full context for a specific task. But the shift-end record shouldn't be organized by ticket — it should be organized by what's important for the incoming shift to know, which often spans multiple tickets and includes context that doesn't belong in any single ticket.