"Who's available to take on the Durand project next week?" This question, asked during the Monday morning team meeting, invariably produces the same scene in web agencies. Awkward silence. Averted gazes. The director looks at the project managers. The project managers look at their teams. Everyone feels overwhelmed, but nobody can quantify it. The director ends up assigning the project to the team member who protested the least -- not the one who actually has bandwidth.
This scene repeats every week in hundreds of web agencies in France. It illustrates a systemic problem: team workload is invisible. Not because people hide their schedules, but because no system makes the workload readable. And when workload is invisible, assignment decisions are poor, the most reliable team members are overloaded, and those who could absorb work remain underutilized.
Why actual workload is invisible without structured tracking
In a web agency, workload is an elusive object. It can't be reduced to the hours in a calendar. A developer may have "only" 6 hours of meetings in a week and feel overwhelmed because the remaining 30 hours are fragmented across 5 projects with competing deadlines. A project manager may have a sparse calendar and actually be saturated by coordination, client follow-ups, feedback to process, and decisions to make.
The calendar doesn't show the workload. Google Calendar or Outlook shows meetings. It doesn't show production time between meetings. A developer with 2 hours of calls in the morning and 1 hour in the evening theoretically has 5 hours of available production time. In reality, fragmentation reduces this effective capacity to 3 or 4 hours, because context switching between projects has a real cognitive cost.
Project management tools show tasks, not workload. Jira, Asana, Trello, Notion -- all these tools list tasks assigned to each team member. But a list of 12 tasks says nothing about actual workload. What's the estimated duration of each task? Are there dependencies? Blockers? The fact that a team member has 12 open tickets in Jira doesn't mean they're working on 12 things simultaneously, nor that they're overloaded.
Team members themselves don't know. When you ask a team member if they're available, the answer is almost always the same: "It depends." It depends on when exactly, for how long, on the priority compared to other projects. This response isn't unwillingness -- it's the genuine inability to quantify one's own workload without structured data.
Key figure: According to a Gallup study, 44% of employees report frequently feeling stressed at work. In communication and digital agencies, this figure rises to 58% according to the 2024 Lex Persona / Occurrence barometer. Perceived overload -- whether real or not -- is a dominant factor.
The result: assignment decisions made by guesswork. Without visibility into actual workload, the agency director or head of production navigates by instinct. They assign the new project to the team member they know best, to the one who says no the least, or to the one they have the impression has "less stuff going on." These impressions are often wrong. And the consequences cascade: delays, errors, frustrations, departures.
The consequences of poor workload distribution
Poor workload distribution doesn't produce a single problem. It produces four, which reinforce each other.
The silent burnout of top performers
The first effect is paradoxical: the most competent and reliable team members are systematically overloaded. Not out of malice from management, but due to a reliability bias: important projects are entrusted to people you trust, without checking whether they have the capacity to absorb them.
A senior developer who always delivers on time and without bugs becomes the repository for every emergency. Week after week, their workload increases by 5%, then 10%, then 20%. They compensate by working evenings and weekends, without saying anything. The day they break -- sick leave, resignation, simple productivity collapse -- the agency loses its operational pillar and discovers that 30% of production depended on a single person.
Key figure: The cost of replacing a skilled employee (recruitment, onboarding, productivity loss) is estimated at 6 to 9 months of salary. For a senior developer at 48,000 euros gross annual salary, that represents 24,000 to 36,000 euros. That's the price of undetected poor workload distribution.
Accelerated turnover
Burnout doesn't always end with sick leave. More often, it results in a departure. The overloaded team member begins by emotionally disengaging. They do the minimum. They stop suggesting improvements. They update their LinkedIn profile. Then they leave, often for a competitor who promises them "a better balance." The agency is surprised. "We didn't see it coming." Of course you didn't see it coming: you weren't looking at the data.
Web and communication agencies show an average turnover of 20 to 25% per year, well above the national average. A significant portion of these departures is linked to workload. Not absolute workload -- you can work 45 hours a week if the work is stimulating and well-distributed -- but poorly distributed, unfair, invisible, and therefore unrecognized workload.
The multiplication of errors and delays
A team member juggling 6 projects without sufficient bandwidth doesn't produce 6 correct deliverables. They produce 6 approximate ones. Bugs increase. QA feedback multiplies. Deadlines slip. The project manager spends more time compensating for delays than managing the project. The overload loop reinforces itself.
The underutilization of available resources
While some team members are overloaded, others are underutilized. It's not that they're less competent -- it's that they're less visible, less vocal, or simply assigned to projects in a client-waiting phase. Without an overall view of the workload, the head of production doesn't see that the junior designer has 15 hours of availability this week while the senior designer is working 50 hours.
Key takeaway: Poor workload distribution is not an individual time management problem. It's a systemic organizational problem. Solving it requires visibility -- factual data on who does what, how many hours, on which project, with what remaining capacity.
How to build a workload view from time tracking
Visibility into team workload doesn't require a complex resource planning tool. It builds naturally from a simple data point: time spent per team member, per project, per week. It's time tracking, properly structured, that provides this visibility.
Step 1: Define the reference capacity
Each team member has a theoretical weekly capacity. For a full-time employee working 35 hours, the actual productive capacity (excluding recurring meetings, breaks, admin) is generally between 28 and 32 hours. This figure varies by role:
| Role | Gross capacity | Meetings / admin | Productive capacity |
|---|---|---|---|
| Senior developer | 35 h | 5-7 h | 28-30 h |
| Junior developer | 35 h | 3-5 h | 30-32 h |
| Project manager | 35 h | 12-15 h | 20-23 h |
| UI/UX designer | 35 h | 5-8 h | 27-30 h |
| Front-end integrator | 35 h | 3-5 h | 30-32 h |
| Head of production | 35 h | 15-20 h | 15-20 h |
Key takeaway: Don't confuse gross capacity with productive capacity. A project manager who spends 15 hours a week in meetings, client calls, and coordination has only 20 hours of effective production time. Assigning them 30 hours of project work is putting them in overrun before they even start.
Step 2: Collect time spent per project and per team member
Time tracking, when entered daily by each team member, produces the workload matrix that makes everything visible. Here's an example for a typical week in an 8-person agency:
| Team member | Project A | Project B | Project C | Project D | Project E | Total | Capacity | Variance |
|---|---|---|---|---|---|---|---|---|
| Marie (senior dev) | 12 h | 8 h | 6 h | 4 h | 3 h | 33 h | 28 h | +5 h |
| Thomas (senior dev) | -- | 15 h | -- | 10 h | 6 h | 31 h | 28 h | +3 h |
| Julie (junior dev) | 8 h | -- | 12 h | -- | -- | 20 h | 31 h | -11 h |
| Lucas (designer) | 6 h | 10 h | -- | -- | 8 h | 24 h | 29 h | -5 h |
| Camille (integrator) | -- | 5 h | 15 h | 4 h | -- | 24 h | 31 h | -7 h |
| Karim (project manager) | 8 h | 6 h | 5 h | 4 h | 3 h | 26 h | 21 h | +5 h |
| Sophie (project manager) | -- | -- | 4 h | 10 h | 8 h | 22 h | 21 h | +1 h |
| Antoine (head of prod.) | 2 h | 2 h | 2 h | 3 h | 2 h | 11 h | 18 h | -7 h |
This table, even simplified, immediately reveals three critical pieces of information:
Overloads are identified. Marie, Thomas, and Karim are above their productive capacity. Marie is juggling 5 simultaneous projects -- a fragmentation signal that destroys productivity.
Underloads are identified. Julie has 11 hours of availability. Camille has 7. These hours aren't "wasted" if projects are in client-waiting mode, but if projects are running late in parallel, it's an assignment problem.
The distribution by project is visible. Project E involves 4 different people for a total of only 17 hours. Does this project justify so many context switches? Could it be concentrated on 2 people instead of 4?
Step 3: Cross-reference workload with project milestones
The workload view reaches its full power when cross-referenced with project milestones. If Project B is in QA phase (deadline Friday) and Thomas is dedicating 15 hours to it this week, that's consistent. If Project A is in scoping phase (deadline in 3 weeks) and Marie is spending 12 hours on it, that's perhaps excessive at this stage.
The workload/milestone cross-reference allows anticipating peaks and troughs. If three projects enter the development phase the same week, the workload table immediately shows that the development team will be saturated. The head of production can then push one project back by a week, bring in an external contractor, or renegotiate a deadline with the client. The decision is made 5 days in advance, not on Monday morning when everyone is already underwater.
To identify the early signals of a portfolio slipping out of control, our article on warning signs in multi-project agency management complements this approach.
Making better assignment decisions
Visibility into workload is not an end in itself. It's a decision-making tool. Here are the four operational decisions that the workload view makes possible.
Assign a new project to the right person
Instead of asking "who's available?" in a meeting (and getting biased answers), the head of production consults the workload table. Julie has 11 hours of availability. Lucas has 5. Camille has 7. The new project requires 15 hours of front-end development this week. The rational decision: assign the project to Julie (11 hours) and supplement with Camille (4 hours). Marie, already overloaded by 5 hours, is not solicited. The decision protects Marie and uses Julie's available capacity.
Distribute workload across profiles
When a team member is overloaded, the instinctive reaction is to "help" by removing a project. The workload view enables a more nuanced approach: identify tasks that can be delegated to a more junior profile. Marie (senior dev) is spending 6 hours on Project C for integration tasks. Julie (junior dev) is available and capable for these tasks. The transfer frees up 6 hours of senior capacity without affecting deliverable quality.
Anticipate overloads 1-2 weeks ahead
This week's workload table is a lagging indicator. The real value is in the projection. If the schedule shows that three projects are entering the development phase next week, the current workload table allows calculating each developer's residual capacity and identifying bottlenecks before they occur.
A well-built dashboard integrates this forward-looking dimension and makes it actionable for the agency director.
Communicate with clients on a factual basis
Visibility into workload also enables factual communication with clients. "We cannot deliver the mockup by Friday because our designer is assigned full-time to another project until Wednesday" is a clear and professional message. "We're doing our best but things are complicated right now" is a weak message that erodes trust.
Concrete example -- Before/After:
Before (without workload visibility): The agency director accepts a new urgent project without checking team availability. The project is assigned to Marie, already overloaded. Marie works 48 hours that week. Quality drops on two of her other projects. A client complains. Marie takes sick leave the following week. The agency must redistribute 5 projects urgently.
After (with workload visibility): The agency director consults the workload table before accepting the new project. They see that Marie is at 118% capacity, but Julie is at 65%. They assign the project to Julie with a brief from Marie (1 hour). Julie delivers the project on time. Marie maintains a sustainable workload. No client complains. Nobody breaks down.
Key takeaways
Team workload is the blind spot of most web agencies. Not because directors are incompetent, but because workload is structurally invisible without a properly implemented time tracking system. The consequences are measurable: burnout of top performers, accelerated turnover, cascading errors, underutilization of available resources.
The solution doesn't require complex resource planning software. It requires three things: a reference capacity per team member, daily time tracking by project and milestone, and a summary table that cross-references these two data points. Agencies that implement this visibility make better assignment decisions, distribute workload more equitably, and anticipate peaks instead of enduring them. The time invested in building this visibility is the best operational investment an agency director can make.