The Work Before the Work: Why Engineers Have to Hunt for Context Before They Can Start Implementation

A bug might first surface in Slack, where a few people discuss what could be causing it, what they have already tried, and how they think it should be resolved. Someone eventually turns that discussion into a Jira ticket, but only part of what was learned makes it into the ticket. The conversation moves to other things, the ticket joins the backlog, and a week or two later it is picked up by an engineer who was not part of the original discussion.

The ticket contains enough information to identify the problem but doesn’t provide enough context to understand it. The engineer can see what needs attention, but not necessarily what has already been investigated, which possibilities were ruled out, why the team settled on a particular approach, or even the steps needed to reproduce the issue. Those details were established earlier, but they did not all make the transition from the discussion into the ticket.

So before the engineer can start fixing the bug, they have to reconstruct what happened. They search the original Slack thread, check the relevant design or comments in Figma, and piece together the decisions and previous investigation that led to the work now sitting in front of them. The ticket made it through the handoff; much of the reasoning behind it did not.

That reconstruction is the work before the work: the time spent recovering enough of a task's history, decisions, and intent to begin executing it with confidence.

How much time do engineers lose hunting for context? 

Fifteen or twenty minutes spent searching for an old discussion or checking a design file may not seem significant. But this is time spent before the engineer can begin the task, and the same problem can recur whenever work is passed to another person or team without the supporting decisions and investigation moving with it.

Ajay, an engineer at Quely, described what this looked like in his workflow before he moved to Quely. Picking up a task could mean, in his words, “context hunting between Slack, Figma, and other apps” to understand what had already happened. He estimates that this could take 15 to 20 minutes per task before he starts working.

The cost goes beyond those minutes. An engineer may repeat an investigation someone has already completed, miss a decision that changes how the work should be approached, or interrupt a teammate who remembers what happened. And if what they recover is not preserved for the next person, this same process happens again if the work moves to someone else.

Why does important context disappear from engineering tickets? 

This problem recurs because important information is created at different stages of the work, by different people, in different tools. Even on well-run teams, some of that information doesn't make it into the ticket, while other details change after the ticket has been created.

A ticket captures what is known at the time of its creation, but the work rarely stops evolving. Investigation continues, designs change, questions are answered, and new constraints emerge. Some of those updates are updated in the ticket; others remain in the Slack thread, Figma comment, or meeting where the conversation happened.

The person creating the ticket also has an advantage that the person who implements it may not have: they were there for the conversations that came before it. They know why a particular approach was chosen, what alternatives were considered, and which details everyone already understands. Because that knowledge feels obvious at the time, some of it is not documented. When another engineer picks up the work weeks later, those same details are no longer obvious at all.

This is how the info in a ticket and the team's understanding of the work gradually diverge. The ticket may still contain the original description and acceptance criteria even though a later discussion changed part of the approach, uncovered a dependency, or ruled out an option. Unless someone deliberately goes back and records each of those changes, the most current reasoning remains outside the ticket.

Time and handoffs make this gap more visible. The engineer who joins the work later cannot rely on the shared memory of the people who investigated or scoped it. They have to recover decisions and constraints from the places where those conversations happened.

The consequences show up long after the original work is finished. In one Reddit discussion, a team described repeatedly revisiting decisions that had already been made because nobody could clearly remember the reasoning behind them, the trade-offs that were considered, or the alternatives that had already been ruled out.

The problem was not that the team had forgotten what decision they reached. They had lost enough of the reasoning behind it that the decision could no longer be evaluated with confidence. As a result, resolved questions were reopened, and the same discussions had to happen again.

This is another form of the same problem: when the history behind a decision is not preserved, subsequent teams have to reconstruct it before they can move forward.

Why better tickets and more documentation don’t fully solve the problem 

The usual fixes help, but each one solves only part of the problem.

Write better tickets. This is worth doing. A well-written ticket gives the next person a much better starting point, but it still depends on someone updating it as the team’s understanding of the work changes. A ticket that accurately reflects the work on Monday can be out of date by Thursday if a subsequent discussion changes the approach and that decision is not added to the ticket.

Document everything. Documentation can preserve decisions, technical reasoning, and other details that will matter later, but someone still has to decide what should be recorded and keep it current. When an important discussion happens in Slack or during a call, who turns it into documentation? When do they do it? And who makes sure that document still reflects the latest decision? In one r/EngineeringManagers discussion about moving important Slack conversations into documentation, those questions were exactly where teams struggled. The difficulty was not recognizing that Slack should not be the permanent record; it was maintaining that record as the work continued to change.

Search the conversation. Search makes it easier to find the Slack thread, comment, or document where something was discussed. It does not necessarily tell you what was decided. Finding the conversation is not the same as understanding it. An engineer may still need to read through a long thread to work out which options were considered, what the team eventually agreed to, and whether anything changed afterward.

Ask the person who knows. Sometimes this is the fastest way to get an answer. But when the same people repeatedly have to explain past decisions, access to that history starts to depend on who remembers it. One engineering lead described realizing they had become the “integration layer” between information spread across GitHub, Linear, email, RFCs, and notes. The immediate question gets answered, but the next person may still have to ask again, creating another interruption and leaving the underlying information problem unchanged.

None of these approaches are wrong. The limitation is that they still leave someone responsible for reconstructing the relevant history when the work is picked up. The harder problem is making it easy to recover the decisions, rationale, previous investigation, and changes behind a task without piecing them together from scratch each time.

What changes when you no longer have to search across different tools for the discussions and decisions behind a ticket 

This is the problem we are solving in Quely. Quely is a context layer for product and engineering teams. It gives your team one Space to discuss a piece of work and bring in the supporting material around it, such as documents, designs, links, and other relevant information. Instead of having to search across different tools to understand what has already happened, the team has one place to find the discussions, decisions, and supporting information behind the work.

Ajay’s workflow shows what this looks like.

When Ajay picks up a ticket in Quely, he is not looking at the ticket in isolation. He can review the discussions around it, open the Slack thread or Figma design that has been added to the Space, and refer back to previous meetings and other supporting material connected to the work. Rather than starting with the ticket and then searching through different tools to figure out where the relevant information might be, he has one place to find and understand what has already happened.

This changes the kind of work Ajay described earlier. In his previous workflow, he could spend 15 to 20 minutes moving between Slack, Figma, and other tools to reconstruct the discussions and decisions he needed before starting a task. With the relevant material connected to the work in Quely, he no longer has to begin each task by independently searching for those pieces of information.

But making the source material easier to find only solves part of the problem. An engineer can have the Slack thread, design, comments, and meeting transcript in front of them and still need to answer a simple question: what did we ultimately decide?

That is where Orbit, Quely’s AI assistant, becomes useful.

 Finding the discussion is not the same as knowing what was decided 

Having the relevant material together solves one part of the problem: finding information quickly. It does not solve the next one, which is understanding what that material tells you.

An engineer may have the Slack thread, meeting transcript, design, comments, and ticket in front of them and still need to answer a simple question: what did we decide?.

Having the relevant discussions, designs, and meeting records in one place makes them easier to find, but you may still need to read through them to understand what was decided, what changed, and which details still matter. 

Finding the conversations and supporting assets is one step. Understanding what it means for the work is another. 

This is where Ajay uses Orbit, Quely’s AI assistant. He can ask Orbit to summarize discussions and extract any information based on conversations, meeting notes, and assets in a Space instead of reading back through each source manually.

The value is being able to ask a question about the work and get an answer drawn from the discussions, meetings, and other information already connected to it. Quely reduces the work of locating the relevant material; Orbit reduces the work of reading through that material to find an answer.

Here's a quick interactive demo that shows you how Quely gives you one space to have conversations about work and bring in supporting assets like documents, links, and more, giving you one place to understand and find any information about work without searching across multiple tools.

Which engineering meetings can move async? 

One major benefit is that some of the coordination Ajay’s team previously handled in meetings can now happen asynchronously.

Ajay describes the meetings he found most frustrating as the ones where engineers were expected to attend even when they did not need to contribute. In those cases, someone might join the call, stay muted, and leave without gaining much from being there.

Now, his team handles several recurring parts of the sprint differently. Standups happen asynchronously, parts of sprint planning can be completed without getting everyone on a call, and retrospectives can be recorded in Quely. When someone has a blocker or a question that genuinely needs discussion, they can still schedule time with the relevant person.

Ajay estimates that this way of working has reduced the number of meetings he attends by around 80 percent. The exact percentage is less important than what changed: routine updates, estimation, and retrospective input can happen asynchronously, while the team still schedules a live meeting when a blocker, question, or decision requires a real-time discussion. 

The goal is not to eliminate meetings. Rather, it is to stop needing a meeting for work that can be handled just as effectively without pulling everyone into the same call.

What should happen when a ticket changes hands? 

The problem is not that product and engineering teams use different tools for different parts of the work. They will continue to do that. The problem appears when someone needs to act on a work item but cannot easily recover the decisions, reasoning, and previous investigation that shaped it.

This becomes critical at handoffs. The person picking up the work may not have been part of the original discussion, may not know which options were considered, and may have no way to tell whether the ticket still reflects the latest thinking. Before they can solve the technical problem, they first have to reconstruct what happened before the work reached them.

The more often work changes hands, the more important it becomes to preserve that history in a way the next person can actually use. The goal is not to force every team into one tool. It is to make sure that when someone picks up a task, they can understand the discussions, decisions, and previous investigation behind it without having to rebuild that history from scratch.