How to Know What Your Team Is Working On

Ask most managers what their team is working on right now and the answer comes back as a half-remembered impression, patched together from yesterday’s meeting, a few chat messages, and a hunch. The more the team grows, the worse the guess gets. Knowing what your team is working on should not depend on memory or on asking people one by one — it should be a property of the system you work in. This guide shows you how to build that system: assigned tasks with owners in a visible board, a standup that answers three questions, work-in-progress limits, a workload view, and async check-ins for remote teams. Plus the real tools that make each piece work.

Quick Answer: how to know what your team is working on

You know what your team is working on when every task has an owner, a status, and a due date in one visible place, and a daily standup surfaces progress, plans, and blockers. The information should come from the system you work in, not from asking people one by one. Add a workload view and async check-ins for remote teams, and the picture stays current without a single interruption.

Why don’t I already know what my team is working on?

Because the information is scattered. Tasks live in personal to-do lists, email drafts, chat threads, someone’s notebook, and a shared board that is updated weekly — if at all. Each person knows their own slice; no one has the whole picture, least of all the manager. Three structural reasons keep this true even in well-intentioned teams:

1. Work happens in private places. A task typed into a personal list or a chat message is invisible to everyone else.
2. Status is updated in bursts. Teams sync the board once a week before a meeting, so the board is a snapshot of the past, not a live view.
3. People avoid announcing uncertainty. Nobody writes “I’m stuck” in a shared tool voluntarily; blockers surface only when someone asks directly.

The fix is not to ask more — it is to make the shared system the natural place where work happens, so the information is created as a byproduct of doing the work.

How do I see everyone’s work without asking them one by one?

Build a shared board where every piece of work is a visible card with an owner, a status, and a due date. The board becomes the one place you look to answer “what is everyone working on?” in about ten seconds.

The board works when three rules are enforced:

• Everything is on it. Personal lists and “just a quick thing” items are banned — if it is not on the board, it does not exist.
• Owners are explicit. Each card has one named owner, so you know who is accountable for each piece of work.
• Status is current. People move cards as they work, not the day before a meeting.

A Kanban-style board with columns like Up Next, In Progress, Blocked, and Done gives the highest visibility for the lowest effort. Blocked is the column that matters most: if you can see every stuck task with its owner and a reason, you know both what people are working on and what is silently stopping them.

What should I do if the board is always out of date?

Treat an outdated board as a workflow problem, not a discipline problem. Check for one of these causes: people do their real work in a different tool (then move the work into the board tool), updates are seen as admin overhead (then make it part of the standup so it takes two minutes), or there are too many statuses to maintain (then simplify to four or five columns). The board that people actually maintain is the one that is also the place of work — not a mirror of it.

What should a standup actually cover so I stop guessing?

A standup is a short, daily, same-time meeting where each person answers three questions:

1. What did I complete since the last standup?
2. What am I working on today?
3. What is blocking me?

That is the whole formula. The three-question format works because it produces exactly the visibility you need — movement, current focus, and obstacles — in 15 minutes or less for a team of ten. It also produces the board update: after each person speaks, their cards are moved and statuses are corrected.

Three rules keep the standup from rotting into a status theater:

• Keep it daily and short. The value is the cadence, not the depth. If it becomes a 45-minute planning session, you have two separate meetings that should not be merged.
• Surface blockers loudly. The third question is where real information lives. If nobody ever says “blocked,” you are either doing great or no one trusts the format.
• Don’t solve problems in the standup. Capture the blocker, assign the unblocking conversation to the two people involved, and end on time. The standup is a visibility ritual, not a working session.

What is the difference between a standup and a status meeting?

A standup is daily, short, equal participation from every member, and focused on today’s movement and blockers. A status meeting is usually weekly, longer, and often a report-to-the-manager exercise. If you run both, keep them separate: the standup for movement and blockers, the weekly meeting for planning and decisions. Merging them usually kills the standup’s speed and the meeting’s focus.

How do work-in-progress limits help me know what people are doing?

A work-in-progress (WIP) limit caps how many tasks can be in progress at once — per person or per column. It creates visibility indirectly: when someone cannot start a new task because their WIP is full, the board shows it, and the conversation about priorities happens in the open.

The practical benefit is that WIP limits kill the illusion of progress. Teams with no limits show twenty cards “in progress” while nothing finishes. A limit forces the truth onto the board: if five tasks are in progress and the limit is three, two of them are not really being worked on — and now everyone can see that.

A common starting point is a WIP limit of two or three tasks per person. If a task sits in In Progress for several days with no movement, that is a signal to ask one focused question instead of a general “how’s everything going?”

What is workload management and why does it matter for visibility?

Workload management is knowing how much each person has on their plate at any time and whether that matches their capacity. It matters because “who is working on what” and “who is drowning” are the same question seen from two angles. A workload view shows:

• Tasks per person and the estimated or actual effort behind them.
• Distribution across the team — who is overloaded, who is light.
• The impact of new requests: accepting this work means delaying that work.

A realistic example: a 9-person team where two people carry 60% of the active tasks. The board alone does not show this; a workload view makes it visible, and the manager can rebalance before burnout or missed deadlines, rather than after.

Workload management is not about tracking hours for surveillance. It is the planning input that makes “yes, we can take that” and “no, we’re at capacity” into honest, evidence-based answers.

How do I track work in remote or async teams?

For distributed teams, the shared board becomes even more important, because there is no hallway visibility. Three practices give async teams the same picture:

1. Async check-ins. Instead of a live standup, each person posts a two-minute update to a dedicated channel or the board daily — what I finished, what I’m doing, what’s blocking me. Everyone can read the thread on their own schedule.
2. A board-first culture. All work and status live on the board; chat is for conversation, not for task truth. If a decision is made in chat, it gets reflected on the board within the day.
3. A weekly written summary. One short recap per week — completed, in progress, blocked, next week — replaces the status meeting entirely and gives stakeholders a stable artifact.

The trade-off: async check-ins require more writing discipline and lose the spontaneous energy of a live standup. The benefit: time-zone freedom, a written record, and visibility that does not depend on everyone being online at once.

How often is too often to check on your team?

Checking in daily through a shared system is fine — that is what the system is for. The problem is direct, personal checking that makes people feel watched: individual Slack messages asking “status?”, multiple meetings about the same work, or demands for updates outside the system. The rule of thumb: let the system answer routine questions, and use personal contact for coaching, support, and judgment calls. If you are asking about things the board already shows, you have a system problem, not a curiosity problem.

What should I do with the information once I have it?

Visibility without action is just surveillance. Put the picture to work with four moves:

1. Reallocate. When the board and workload view show imbalance, reassign work or reprioritize — visibly, with the reasons.
2. Unblock. When blocked tasks accumulate, clear them at the source: remove a dependency, answer a question, provide a missing decision.
3. Plan. Use the current picture to make accurate promises about what can be delivered next — capacity becomes a fact, not a guess.
4. Coach. One-on-one conversations shift from “what are you doing?” (answered by the board) to “how is it going, and what would help?” — which is the conversation that actually builds performance.

The test of good visibility is whether it changes what you do. If you look at the board and the workload view every day but never act on them, you have built a dashboard, not a management system.

Which tool fits my team? Real tools with pros, cons, and trade-offs

Here are the realistic options, with honest trade-offs.

Jira. The strongest for engineering teams. Pros: boards, sprints, and workload views that compute from real task data; deep reporting. Cons: overkill and intimidating for non-technical teams; setup takes commitment. Trade-off: choose it if you run Scrum or need engineering-grade tracking; it will fight you elsewhere.

Asana. Excellent general-purpose visibility. Pros: clear task assignments, dependencies, timeline, and workload features; easy for non-technical stakeholders. Cons: can get noisy; some advanced views need paid plans. Trade-off: the best all-rounder for mixed teams that need to see ownership and progress in one place.

Trello. The simplest board. Pros: instant to learn, visually obvious, ideal for small teams; WIP limits are easy to impose. Cons: weak for workload, reporting, and dependencies. Trade-off: perfect when a simple board is the whole answer; it stalls at scale.

monday.com. Highly visual with strong dashboards and automation. Pros: the board itself is the visibility; stakeholder-friendly views; good for operations and marketing. Cons: per-seat cost climbs; over-customization makes boards fragile. Trade-off: strong if you want a stakeholder-readable picture without heavy config.

Slack or Teams plus a board. Many teams pair chat with a board tool. Pros: people already live in chat; quick questions get fast answers. Cons: work living in chat recreates the invisibility you are trying to kill. Trade-off: acceptable only if the rule “the board is the source of truth” is actually enforced.

No tool solves this alone. The common denominator is the workflow: owners, current status, and a review cadence. Tools make that workflow easy or hard; they do not create it.

Real scenarios: knowing what the team is doing

Scenario 1 — Small design team (4 people). A team lead loses a day a week to status-chasing across Slack and email. Fix: all tasks move to a shared board with owners and due dates, plus a 10-minute daily standup. Result: status-chasing drops to near zero, and the lead reallocates the saved half-day to planning — about 4 hours a week.

Scenario 2 — Engineering team, hidden blockers (10 people, Jira). A team discovers at sprint review that a dependency has been silently stalled for three sprints. Fix: a Blocked column with an owner and a reason on every stuck task, and a WIP limit of two per person. Result: the next stalled dependency is visible within 48 hours, and the team unblocks or reprioritizes instead of waiting for the review.

Scenario 3 — Remote ops team (14 people, three time zones). A distributed team cannot run a live standup. Fix: async check-ins in a dedicated thread plus a board-first culture. Result: visibility is restored without a single meeting, and the weekly written summary replaces the status meeting entirely.

Scenario 4 — Agency, workload imbalance (18 people, monday.com). Two senior people carry most active tasks while three juniors sit idle. Fix: a workload view reviewed every Friday before new work is accepted. Result: within six weeks the load is visibly rebalanced, overdue tasks drop by roughly a third, and juniors take on stretch work with clear ownership.

Common Mistakes

• Work living in chat. Chat is for conversation; when task truth lives in chat, it is invisible. Enforce “the board is the record.”
• Weekly-updated boards. A board updated the day before a meeting is a memory aid, not visibility. Update as work happens.
• Standups that are actually status reports to the manager. If the standup is one-way reporting, you lose the three-question cadence that surfaces real blockers.
• No WIP limits. Unlimited in-progress columns show an illusion of busyness and hide what is actually being worked on.
• Checking on people instead of checking the system. Asking “status?” for things the board shows trains people to expect surveillance. Fix the system, not the asking.
• Surveillance without action. Visibility you never act on is just cost. Every view should feed reallocation, unblocking, or planning.
• Micromanaging the process. Knowing what people work on is not the same as controlling how they do it. Watch outcomes and blockers, leave the method alone.

Know This Before You Choose

Before you build your “who is doing what” system, answer these:

• Does every piece of work have one named owner and a current status in one shared place?
• Is the board updated as work happens, or only before meetings?
• Do we have a daily (or async) ritual that surfaces blockers?
• Do we limit work in progress, so “in progress” actually means something?
• Can I see each person’s total load at a glance?
• Are decisions made in meetings reflected on the board the same day?
• Will the tool survive contact with the team’s existing habits (chat, email, personal lists)?
• Who enforces the workflow so it does not decay in the first month?

If you are unsure, start with the smallest board your team will accept and enforce two rules only — every task on it, every task with an owner — before adding anything else.

Where Doitify fits: the whole picture in one workspace

When the answer to “what is everyone working on?” lives across a board, a chat app, and a spreadsheet, you are stitching visibility together by hand. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. Doitify brings tasks, sub-tasks, and checklists with owners and due dates into one workspace, with Kanban boards for the daily view, workload and resource management so you can see who has capacity, team chat for the conversations, and work and performance reports for the bigger picture. Teams that want one system instead of three can evaluate it against the workflow principles in this guide — and small teams with simple needs should still consider a single well-run board first.

Conclusion

Knowing what your team is working on is a system outcome, not a personal talent. Put every task on a shared board with an owner and a due date, run a short three-question standup (or async check-ins for remote teams), limit work in progress, and watch the workload view before promising anything new. The information then flows to you as a byproduct of doing the work — no chasing, no guessing. Use the visibility to reallocate, unblock, plan, and coach, not just to observe. If your team’s picture is scattered across chat, boards, and spreadsheets, a unified workspace such as the one described in our project-management hub is worth a serious look.