What Are You Working on? How to Answer & Stay Focused

You're deep in a task, finally holding the full shape of it in your head, and then the ping lands.

What are you working on?

Sometimes it comes from your manager. Sometimes it comes from a cross-functional partner. Sometimes it comes from someone who means well and just needs context. But the effect is the same. You stop doing the work so you can explain the work, and if the team asks often enough, your real job starts to feel like producing little fragments of reassurance on demand.

That's why most advice on this topic feels incomplete. It focuses on the perfect reply, as if the problem is wording. Usually it isn't. The core issue is that a lot of teams still rely on ad hoc visibility. Individual contributors feel watched. Managers feel blind. Everyone gets dragged into unnecessary context switching.

The Interruptive Question We All Dread

You are twenty minutes into a hard piece of work. The logic finally fits together, or the draft starts to cohere, or the bug reproduces cleanly. Then a message appears.

What are you working on?

That question creates friction because it arrives at the worst possible moment. It usually comes as a quick DM, a hallway follow-up after a meeting, or a channel message sent on behalf of someone upstream who wants a summary. The person asking often has a reasonable need. The person answering still has to stop, reconstruct context, and translate active work into a clean status update.

I have watched this go wrong from both seats. ICs often hear scrutiny in the question, especially on teams where visibility is inconsistent and priorities change without warning. Managers often mean something narrower and more practical: What changed, what is blocked, and what do I need to know before someone else asks me? Same sentence. Very different stakes.

The cost is not the 30 seconds it takes to type a reply.

The cost is the context shift. Deep work depends on holding moving parts in working memory. A status ping forces a switch from doing the work to explaining the work, then another switch back into the task. Teams can absorb that once in a while. They struggle when it becomes the default way progress gets tracked.

Poor communication systems also create delivery risk at the team level. PMI has long documented communication as a recurring factor in project outcomes. The useful takeaway here is simple: repeated status interruptions are rarely an individual communication problem. They are usually a sign that the team lacks a reliable way to make work visible.

Practical rule: If people repeatedly need to ask what you're working on, the team has a visibility problem.

The pattern is easy to recognize once you have seen it a few times:

• Updates happen only on request: People learn what is moving only after they interrupt someone.
• Status lives inside meetings: Anyone who missed the call misses the context.
• The record is fragmented: One detail is in Slack, another in email, another in a tracker people barely trust.
• Completed work fades fast: The team remembers the loudest work, not the work that shipped without fanfare.

A polished answer can smooth over one interruption. It does not fix the operating model that created the interruption in the first place. Better teams do not train people to give nicer ad hoc updates. They build systems where progress, blockers, and priorities are already visible before anyone has to ask.

Why Managers Ask What You Are Working On

A lot of ICs hear this question as suspicion. Sometimes that reading is fair. Often it isn't.

Most managers ask because they're missing something they need to do their job well. The problem is that “what are you working on?” is an overloaded question. It can mean five different things depending on the moment, and the person answering has to guess which one.

The question behind the question

When a manager asks, they may be trying to learn any of the following:

That ambiguity is why the question creates so much friction. The words are simple, but the social meaning isn't. Recent workplace research notes that managers are struggling to maintain connection and visibility in distributed teams, with only about 24% of employees saying their employer is effective at keeping them informed and connected in hybrid settings (workplace research note).

Why managers often ask badly

Most managers were never trained to request status well. They know they need clarity, but they ask in the broadest possible way. That broadness shifts the burden onto the person doing the work.

A vague question can hide several urgent concerns:

• Priority check: Are you working on the thing we agreed matters most?
• Progress check: Is this moving, or sitting still?
• Risk check: Is there a blocker you haven't raised yet?
• Reporting need: Do I need a clean summary for leadership, finance, or another team?

None of those are unreasonable. What's unreasonable is expecting a useful answer from a question with no context attached.

Managers usually don't need more updates. They need better visibility into the right updates.

What helps from the IC side

When you understand the likely intent, the question gets easier to answer without sounding defensive. A strong answer doesn't only say what task is open on your screen. It also gives the manager enough context to stop asking follow-up questions.

That means a good answer usually covers three things:

• What matters most right now
• What changed recently
• Whether anything needs attention

Once you start answering at that level, the exchange gets calmer. But even then, the team is still operating manually. Better than friction is not no friction. Better is a system where people don't have to decode each other's anxiety in real time.

A Better Way to Answer and Build Trust

A rushed answer often creates more work than it saves. “Working on the API issue” usually triggers two or three follow-up questions, because it does not tell the other person what changed, what is at risk, or whether priorities are on track.

A better answer is a short progress narrative. For example: “I finished the auth cleanup, I'm fixing the API timeout now, and if that lands today I'll move to the retry logic next.” That gives a manager what they usually need in one pass: progress, current focus, and likely next step.

Use Past, Present, Future

This framework works because it mirrors how teams judge progress. People want to know what moved, what has attention now, and whether the next move still matches the plan.

Past

Start with what changed since the last useful update.

That could be a bug isolated, a draft finished, a stakeholder decision made, or a dependency cleared. Keep it brief. The goal is to establish momentum, not to replay every hour of the day.

Present

State the current focus and the status around it.

This is where good judgment shows up. Name the work, explain why it has priority, and mention any trade-off, risk, or blocker. A senior answer sounds like someone managing the work, not just touching it.

Future

End with what comes next, or what needs a decision.

This is the part that reduces friction over time. It gives the manager a clean chance to redirect priorities before effort gets wasted, and it shows that you are tracking the path, not just the task.

Weak answer versus useful answer

The difference is usually context.

Weak answer

• Working on the dashboard stuff.
• Still in progress.

Useful answer

• I wrapped up the data mapping changes this morning.
• Right now I'm fixing the dashboard filtering bug that was throwing off the metrics view.
• After that I'll validate it with design, unless the billing issue needs to jump the queue.

That second version makes trade-offs visible. It also makes it easier for a manager to help, because they can respond to a real sequence instead of guessing what “dashboard stuff” means.

Why this approach helps beyond the immediate conversation

Good updates are not only for the person who asked. They become part of the record of how work moved, where judgment was applied, and what outcomes followed. That record is useful later in reviews, promotion cases, calibration discussions, and project retrospectives. SHRM's guidance on documenting employee performance reflects the same principle from the management side.

A good update should help the current conversation and your future review.

This is also where tone matters. If the question feels loaded, answer the real need underneath it instead of treating it like a test. Advice on listening to understand what the other person actually needs helps here, especially when a vague ping could mean concern about priority, timing, or risk.

A practical reply template

Use this format when you need a fast answer that still builds trust:

1. What I finished: one line
2. What I'm focused on now: one or two lines
3. What's next or what I need: one line

For example:

Finished the test cleanup for the release branch. I'm focused on the import bug now because it's blocking QA. Next I'll move to the export issue, unless we want to prioritize the customer-reported login problem first.

That answer is clear, grounded, and easy to act on. It lowers the odds of another interruption five minutes later.

How Managers Can Get Updates Without Interrupting

If you're a manager and you find yourself asking what are you working on multiple times a week, the team probably doesn't need more check-ins. It needs a better operating rhythm.

Ad hoc pings feel lightweight to the sender. They rarely feel lightweight to the receiver. Each message asks someone to stop, summarize, and translate. If five different people do that in a week, you've built a hidden reporting system on top of the core work.

Replace surprise with structure

The fix isn't silence. The fix is predictability.

A few patterns work well in practice:

• Dedicated update threads: Keep one Slack thread per project or workstream for concise progress notes.
• Short written check-ins: Ask for updates at a defined cadence, with the same simple format each time.
• Specific questions instead of broad ones: “Are you blocked on the migration?” gets a better answer than “What are you working on?”
• Tight syncs with rules: If you hold a standup, keep it short, decision-oriented, and free of storytelling.

The key is that people should know when and where visibility happens. That lowers anxiety on both sides.

Ask for context, not theater

Managers often trigger rambling updates by asking broad questions in public. People respond by proving effort instead of communicating status. You don't need a tour of every tab they have open. You need enough context to manage dependencies and priorities.

Ask for:

That shift changes the conversation from surveillance to support.

If your team has to keep manufacturing reassurance, they have less energy for execution.

Build ambient awareness

The healthiest teams create visibility as a byproduct of work, not as an interruption layered on top of it. That usually means written updates, searchable history, and habits that don't depend on someone remembering to ask.

For managers trying to move in that direction, why async updates matter is the right frame. The goal isn't fewer words. It's better timing, better capture, and less disruption.

Moving Beyond Pings with Async Work Logs

A familiar scene on busy teams. Someone finally gets into a stretch of focused work, a manager pings for an update, and ten minutes later both people have less clarity than they wanted. The manager still has to piece together status across projects. The IC has broken concentration to reconstruct work from memory.

Async work logs solve a different problem than chat or standups. They create a shared record of progress as the work happens, so visibility does not depend on who asked, who was online, or who happened to remember the right detail in the moment.

McKinsey has written about the productivity gains available when companies reduce collaboration drag and shift routine coordination out of synchronous channels. The practical takeaway is straightforward. Fewer status interruptions usually mean more time for real work, better handoffs, and a cleaner record for managers who need to track progress across a team.

A good async log is light enough that people will keep using it after the first week. It captures what changed, what is next, and where things are stuck. It is searchable later, readable by someone outside the immediate project, and easy to update from the tools people already use.

That last part matters more than teams expect.

If logging work takes too much effort, people stop. If the format is too vague, managers still have to chase context. If the system becomes another bloated tracker, the team now has two problems instead of one. Good work logs sit in the middle. Fast to write. Clear to scan. Useful months later during planning, reviews, and incident follow-up.

For teams that already manage flow visually, a board can still complement the written record. If you need a lightweight setup for task movement, this guide on how to create a Google Kanban board pairs well with async logging. Boards show where work sits. Logs explain what changed and why.

One example of this category is WeekBlast's daily work log app. It lets people send short updates in the app or by email, turns them into a searchable feed, and keeps the record in one place instead of scattering it across chat threads and meeting notes. Features like exports, integrations, API access, and SAML SSO matter less as selling points than as signs of fit. Different teams need different levels of control, and the tool has to match the reporting habits they already have.

Performance matters here too. Collaboration tools live or die on response time and predictability. Engineering teams often evaluate systems with latency budgets, which means breaking total delay into parts and watching tail latency, not just average speed. That is a better standard than asking whether a tool feels fast in a demo. If update capture is inconsistent under normal team load, people fall back to private notes, stale trackers, and more pings.

The primary value of async work logs is not prettier status updates. It is replacing ad hoc visibility with a system people can trust.

Reclaim Your Focus and Tell Your Story

The phrase what are you working on sounds simple. On a lot of teams, it isn't. It carries anxiety about visibility, trust, alignment, and proof. That's why canned answers only go so far.

For individual contributors, the practical move is to answer with a short narrative. Say what changed, what you're focused on now, and what comes next. That helps in the moment, and it leaves behind a clearer record of your work.

For managers, the bar is higher. If updates only appear when you interrupt someone, the team is paying for weak systems with constant context switching. The fix is a predictable rhythm, sharper questions, and shared places where progress lives without needing to be requested.

The bigger shift is cultural. Teams do better when visibility is ambient rather than intrusive. People stay focused longer. Managers get cleaner signals. Reviews get easier because work exists in a usable record, not in fragments of memory.

The best answer to “What are you working on?” is often a system that already answered it.

That's the standard worth aiming for. Not perfect standup scripts. Not more pings. A way of working where progress is documented as it happens, searchable later, and visible without dragging everyone out of their flow.

If your team is tired of status pings and scattered updates, WeekBlast gives you a lightweight way to keep a searchable work log, share async progress, and build a durable record for reviews without adding more meetings.