If it feels like a chunk of every workday quietly disappears into searching for information, it is not your imagination. Multiple long-running studies, from IDC to McKinsey to Gartner, all land on a similar uncomfortable number: knowledge workers lose somewhere between one and three hours each day looking for things that already exist somewhere in their organisation.

That is the famous 30% figure. It is also one of the more abused stats in productivity content, so this article does two things at once. First, it shows where the number really comes from and what it actually measures. Then it digs into why this happens, what people are actually searching for, and what teams in 2026 are doing to cut the time down without adding yet another tool. Along the way you will see how the hidden cost of searching for information at work compounds week after week.

The 30% number, where it comes from, and what it really measures

The "30% of the workday" line traces back to research from IDC, which estimated that the typical knowledge worker spends about 2.5 hours a day, or roughly 30% of the workday, searching for information. The original estimate was based on the spread of intranets and internal repositories: more places to look means more time spent looking.

Other studies in the same family land in the same neighbourhood, with slightly different framings:

• McKinsey Global Institute, in The Social Economy, found that workers spend an average of 1.8 hours each day, or about 9.3 hours a week, searching and gathering information.

• A 2023 Gartner survey reported that 47% of digital workers struggle to find the information they need to do their jobs effectively, and that locating a single document takes around 18 minutes on average.

• Multiple AIIM and IDC follow-ups continue to surface the same pattern: workers regularly check five or six different places before they find what they were looking for, and many give up before they do.

The exact percentage varies by industry, role, and how the survey defines "searching". Sales reps searching a CRM look different from researchers searching a document repository. But the broad picture is consistent across sources: a significant fraction of the day, between 20% and 30% for most knowledge roles, is spent locating information rather than using it.

The numbers are old enough now that they should be a wake-up call, not a headline. The interesting question is not whether the figure is exactly 30%. It is why, after more than a decade of new tools, the pattern has not really moved.

What knowledge workers are actually searching for

The word "information" hides what is really happening. When you slow it down, the day-to-day searching usually falls into five concrete buckets.

A specific decision and the reasoning behind it

"What did we agree on for the pricing tiers?", "Why did we drop that vendor in March?" These are decision searches, and they are the most expensive. They often pull people into meeting recordings, doc histories, and Slack threads, just to reconstruct something the team already knew once.

The latest version of a file or document

Specs with _FINAL_v3 in the name. Decks with three near-identical copies. PDFs sent over email that may or may not match what is in the shared drive. Most teams underestimate how much time goes into figuring out which version is the current one before they can even start working.

A person, an owner, or a point of contact

"Who owns this part of the project?" "Who knows about the integration with their billing system?" When ownership is not visible in one place, finding the right person becomes a small project of its own.

The context behind a project or a customer

New joiners, anyone returning from a holiday, and anyone picking up a customer mid-cycle spend serious time reconstructing context: previous calls, prior decisions, what has been tried, what was rejected. Tools store the artefacts but rarely tell the story.

An answer that has already been given before

The most demoralising category. Someone has already answered this exact question, in chat, in a doc, or in a meeting, but the answer is not findable now. So the question is asked again, and someone re-types the same response.

When you sum these five buckets across a team, the 30% figure stops feeling abstract.

The five structural causes behind the lost time

If the pattern is so persistent, it is worth asking why. The honest answer is that most of the lost time is not caused by lazy habits. It is caused by the way modern work is structured.

1. Information lives in too many places

A typical project touches a chat tool, a doc tool, a project tracker, an inbox, a video call platform, a file storage service, and at least one specialised tool per function. Each one is reasonable on its own. Together they create the classic scattered project information problem, where no single search ever covers the whole picture.

2. Capture is fragmented across formats

Some things end up as documents, others as messages, others as recordings, others as tickets, others as emails. Each format has its own search behaviour. A keyword that finds a doc may not find the call where the same topic was discussed.

3. Search engines are tool-bound, not project-bound

Most search bars only see the tool they live in. They do not understand that a meeting, a Slack thread, an email, and a Notion page might all belong to the same project. This is a direct consequence of tool sprawl: more tools means more silos, not better answers.

4. Decisions are not separated from raw notes

Meeting notes capture what was said. Most do not separate what was decided. So when someone later asks "what did we decide?", they have to read or skim everything to find the moment, instead of jumping straight to it.

5. There is no shared memory across meetings

Even when individual meetings are well documented, most teams have no layer that connects them. Decisions made in one call are invisible to people prepping for the next. This is the gap between traditional notetakers and the more recent idea of project memory.

Notice how each cause feeds the others. Adding a new tool to fix one of them often makes the others worse.

What leading teams are doing differently in 2026

The teams that have visibly cut their search time are not the ones with the most tools. They tend to share three habits.

They centralise the project, not the documents. Instead of asking "where do we put files?", they ask "where does this project live?". One home per project, with everything else linking back. This is the practical heart of project knowledge management.

They separate decisions from notes. A short, dated decisions log lives next to the raw meeting notes. When someone asks "what did we decide?", the answer is one click away, not a fifteen-minute review.

They add a retrieval layer on top of capture. Capturing meetings, emails, and updates is only half the value. The other half is being able to ask the project a question in plain language and get an answer with sources attached. AI tools that work across the project, not just inside one file, are starting to make this routine.

None of these habits requires a six-month rollout. They start with the next meeting and the next decision.

What you can do this week to reclaim some of the 30%

A realistic week of changes looks like this.

• Pick one project as your pilot. Trying to fix everything at once is the main reason these efforts stall.

• Choose one home for that project. Treat it as the [single source of truth] → How to Build a Single Source of Truth for Your Project in 2026 and link everything else back to it.

• Start a decisions log. A simple list with date, decision, reasoning, and owner. Update it within 24 hours of every meeting where something is decided.

• Standardise file naming and locations. A boring rule like [Project] – [Type] – [Date] removes hours of "which version?" searching.

• Audit your tool stack. List every place where project information currently lands. Anything that is not the home should either feed the home or be retired.

• Try a project memory layer. If your team already produces good notes but still loses context between meetings, a tool that reads across meetings, emails, and docs can absorb most of the search work.

Most teams who try this report that the change is not dramatic on day one, but compounds quickly. Two or three weeks in, meetings get shorter, recap time shrinks, and "where is..." messages drop noticeably.